On Fri, Oct 12, 2012 at 2:33 AM, Shea Levy wrote:
>
> FWIW (and probably that's not much), the NixOS[0] distro doesn't currently
> use /lib/firmware. There is no /lib directory by default on NixOS, instead
> we create a new symlink tree representing the current system on each system
> change and
On 10/02/2012 06:37 PM, Linus Torvalds wrote:
On Tue, Oct 2, 2012 at 2:03 PM, Ivan Kalvachev wrote:
I'm not kernel developer and probably my opinion would be a little
naive, but here it is.
Please, make the kernel load firmware from the filesystem on its own.
We probably should do that, not j
Greg KH writes:
> On Thu, Oct 04, 2012 at 10:29:51AM -0700, Eric W. Biederman wrote:
>> There are still quite a few interesting cases that devtmpfs does not
>> even think about supporting. Cases that were reported when devtmpfs was
>> being reviewed.
>
> Care to refresh my memory?
Anyone who w
On Wed, Oct 10, 2012 at 5:19 AM, Felipe Contreras
wrote:
> On Thu, Oct 4, 2012 at 9:17 PM, Alan Cox wrote:
>>> I don't know how to handle the /dev/ptmx issue properly from within
>>> devtmpfs, does anyone? Proposals are always welcome, the last time this
>>> came up a week or so ago, I don't rec
On Thu, Oct 4, 2012 at 9:17 PM, Alan Cox wrote:
>> I don't know how to handle the /dev/ptmx issue properly from within
>> devtmpfs, does anyone? Proposals are always welcome, the last time this
>> came up a week or so ago, I don't recall seeing any proposals, just a
>> general complaint.
>
> Is i
On 5 Oct 2012, Henrique de Moraes Holschuh told this:
> On Fri, 05 Oct 2012, da...@lang.hm wrote:
>> >On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier wrote:
>> >>On Wed, Oct 03, 2012 at 07:27:01PM +, Al Viro wrote:
>> >>>Al, that -><- close to volunteering for maintaining that FPOS
>> >>>kernel
On Fri, 05 Oct 2012, da...@lang.hm wrote:
> >On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier wrote:
> >>On Wed, Oct 03, 2012 at 07:27:01PM +, Al Viro wrote:
> >>>Al, that -><- close to volunteering for maintaining that FPOS
> >>>kernel-side...
> >>
> >>This would be fantastic.
> >
> >And that wo
On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier wrote:
On Wed, Oct 03, 2012 at 07:27:01PM +, Al Viro wrote:
Al, that -><- close to volunteering for maintaining that FPOS kernel-side...
This would be fantastic.
And that would solve this very much worrying issue [1], quoting:
"(Yes, udev o
On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier wrote:
> On Wed, Oct 03, 2012 at 07:27:01PM +, Al Viro wrote:
>>
>> Al, that -><- close to volunteering for maintaining that FPOS kernel-side...
>>
>
> This would be fantastic.
And that would solve this very much worrying issue [1], quoting:
"(Yes,
> I don't know how to handle the /dev/ptmx issue properly from within
> devtmpfs, does anyone? Proposals are always welcome, the last time this
> came up a week or so ago, I don't recall seeing any proposals, just a
> general complaint.
Is it really a problem - devtmpfs is optional. It's a proble
On Thu, Oct 04, 2012 at 10:29:51AM -0700, Eric W. Biederman wrote:
> There are still quite a few interesting cases that devtmpfs does not
> even think about supporting. Cases that were reported when devtmpfs was
> being reviewed.
Care to refresh my memory?
> Additionally the devtmpfs maintainer
Kay Sievers writes:
> If that works out, it would a bit like devtmpfs which turned out to be
> very simple, reliable and absolutely the right thing we could do to
> primarily mange /dev content.
ROFL.
There are still quite a few interesting cases that devtmpfs does not
even think about supporti
On Wed, Oct 03, 2012 at 07:27:01PM +, Al Viro wrote:
>
> Al, that -><- close to volunteering for maintaining that FPOS kernel-side...
>
This would be fantastic.
Kurt H Maier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger
On Tue, 2 Oct 2012, Linus Torvalds wrote:
> Now, at the same time, I do agree that network devices should generally
> try to delay it until ifup time
Slightly tangential to the ongoing discussion, but still ... I think that
even "all network drivers should delay firmware loading to ifup time"
On Thu, Oct 04, 2012 at 09:39:41AM -0400, Josh Boyer wrote:
> > That said, there's clearly enough variation here that I think that for
> > now I won't take the step to disable the udev part. I'll do the patch
> > to support "direct filesystem firmware loading" using the udev default
> > paths, and
On Wed, Oct 3, 2012 at 6:58 PM, Linus Torvalds
wrote:
> On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls wrote:
>>
>> I don't know if you can remove the /sys/.../firmware ABI altogether, because
>> there is at least one, somewhat popular udev replacement that also uses it:
>> mdev
>>
>> http://git.bu
[Kay removed because I don't like emailing arguable flamebait directly
to the person flamed.]
On 4 Oct 2012, n...@esperi.org.uk stated:
> By udev 175 I, and a lot of other people, had simply stopped upgrading
> udev entirely on the grounds that we could no longer tolerate the
> uncertainty over w
On Thu, Oct 4, 2012 at 12:58 AM, Linus Torvalds
wrote:
> That said, there's clearly enough variation here that I think that for
> now I won't take the step to disable the udev part. I'll do the patch
> to support "direct filesystem firmware loading" using the udev default
> paths, and that hopeful
On Wed, Oct 3, 2012 at 6:33 PM, Ming Lei wrote:
>
> Yes, the patch will make firmware cache not working, I would like to fix
> that when I return from one trip next week.
>
> BTW, firmware cache is still needed even direct loading is taken.
I agree 100%, I'd have liked to do the caching for the d
On 3 Oct 2012, Al Viro spake thusly:
> Looks sane. TBH, I'd still prefer to see udev forcibly taken over and put
> into
> usr/udev in kernel tree - I don't trust that crowd at all and the fewer
> critical userland bits they can play leverage games with, the safer we are.
>
> Al, that -><- clos
On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls wrote:
>
> I don't know if you can remove the /sys/.../firmware ABI altogether, because
> there is at least one, somewhat popular udev replacement that also uses it:
> mdev
>
> http://git.busybox.net/busybox/plain/docs/mdev.txt
Heh. That web doc docume
Hi Linus,
On Wed, 3 Oct 2012 13:39:23 -0700 Linus Torvalds
wrote:
>
> Ok, I wish this had been getting more testing in Linux-next or
> something
If you ever want a patch tested for a few days, just send it to me and I
will put it in my "fixes" tree which is merged into linux-next
immediately on
Linus Torvalds wrote:
>On Wed, Oct 3, 2012 at 12:50 PM, Greg KH
>wrote:
>>>
>>> Ok, like this?
>>
>> This looks good to me. Having udev do firmware loading and tieing it
>to
>> the driver model may have not been such a good idea so many years
>ago.
>> Doing it this way makes more sense.
>
>Ok,
On Wed, Oct 3, 2012 at 2:58 PM, Lucas De Marchi
wrote:
>
> So maintaining the fallback or adding a configurable entry to set the
> firmware paths might be good.
Yeah, I do think we need to make it configurable. Probably both at
kernel compile time and dynamically.
The aim of having a user-mode d
On Tue, Oct 2, 2012 at 7:37 PM, Linus Torvalds
wrote:
> On Tue, Oct 2, 2012 at 2:03 PM, Ivan Kalvachev wrote:
>>
>> I'm not kernel developer and probably my opinion would be a little
>> naive, but here it is.
>>
>> Please, make the kernel load firmware from the filesystem on its own.
>
> We proba
On Wed, Oct 3, 2012 at 5:39 PM, Linus Torvalds
wrote:
> On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote:
>>>
>>> Ok, like this?
>>
>> This looks good to me. Having udev do firmware loading and tieing it to
>> the driver model may have not been such a good idea so many years ago.
>> Doing it this
On Wed, 3 Oct 2012 23:18:06 +0200
Kay Sievers wrote:
> On Wed, Oct 3, 2012 at 11:05 PM, Greg KH wrote:
>
> > As for the firmware path, maybe we should
> > change that to be modified by userspace (much like /sbin/hotplug was) in
> > a proc file so that distros can override the location if they n
On Wed, Oct 3, 2012 at 11:05 PM, Greg KH wrote:
> As for the firmware path, maybe we should
> change that to be modified by userspace (much like /sbin/hotplug was) in
> a proc file so that distros can override the location if they need to.
If that's needed, a CONFIG_FIRMWARE_PATH= with the array
Greg KH wrote:
>On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
>> On Wed, Oct 3, 2012 at 10:09 AM, Al Viro
>wrote:
>> >
>> > + if (!S_ISREG(inode->i_mode))
>> > + return false;
>> > + size = i_size_read(inode);
>> >
>> > Probably better to do vfs_getatt
On Wed, Oct 03, 2012 at 01:39:23PM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote:
> >>
> >> Ok, like this?
> >
> > This looks good to me. Having udev do firmware loading and tieing it to
> > the driver model may have not been such a good idea so many years ago.
> >
On Wed, Oct 3, 2012 at 10:39 PM, Linus Torvalds
wrote:
> On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote:
>>>
>>> Ok, like this?
>>
>> This looks good to me. Having udev do firmware loading and tieing it to
>> the driver model may have not been such a good idea so many years ago.
>> Doing it this
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote:
>>
>> Ok, like this?
>
> This looks good to me. Having udev do firmware loading and tieing it to
> the driver model may have not been such a good idea so many years ago.
> Doing it this way makes more sense.
Ok, I wish this had been getting more te
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 10:09 AM, Al Viro wrote:
> >
> > + if (!S_ISREG(inode->i_mode))
> > + return false;
> > + size = i_size_read(inode);
> >
> > Probably better to do vfs_getattr() and check mode and siz
Em 03-10-2012 13:57, Greg KH escreveu:
> On Wed, Oct 03, 2012 at 04:36:53PM +0200, Kay Sievers wrote:
>> On Wed, Oct 3, 2012 at 12:12 AM, Greg KH wrote:
>>
>>> Mauro, what version of udev are you using that is still showing this
>>> issue?
>>>
>>> Kay, didn't you resolve this already? If not, wha
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 10:09 AM, Al Viro wrote:
> >
> > + if (!S_ISREG(inode->i_mode))
> > + return false;
> > + size = i_size_read(inode);
> >
> > Probably better to do vfs_getattr() and check mode and siz
On Wed, Oct 3, 2012 at 10:24 AM, Kay Sievers wrote:
>
> Nothing really "breaks", It's "slow" and it will surely be fixed when
> we know what's the right fix, which we haven't sorted out at this
> moment.
A thirty-second pause at bootup is easily long enough that some people
might think the machin
On Wed, Oct 3, 2012 at 10:09 AM, Al Viro wrote:
>
> + if (!S_ISREG(inode->i_mode))
> + return false;
> + size = i_size_read(inode);
>
> Probably better to do vfs_getattr() and check mode and size in kstat; if
> it's sufficiently hot for that to hurt, we are fucked anyway.
On Wed, Oct 3, 2012 at 6:57 PM, Greg KH wrote:
>> It's the same in the current release, we still haven't wrapped our
>> head around how to fix it/work around it.
>
> Ick, as this is breaking people's previously-working machines, shouldn't
> this be resolved quickly?
Nothing really "breaks", It's
On Wed, Oct 03, 2012 at 09:38:52AM -0700, Linus Torvalds wrote:
> Yeah, that bugzilla shows the problem with Kay as a maintainer too,
> not willing to own up to problems he caused.
>
> Can you actually see the problem? I did add the attached patch as an
> attachment to the bugzilla, so the reporte
On Wed, Oct 3, 2012 at 9:38 AM, Linus Torvalds
wrote:
>
> Anyway. Attached is a really stupid patch that tries to do the "direct
> firmware load" as suggested by Ivan. It has not been tested very
> extensively at all (but I did test that it loaded the brcmsmac
> firmware images on my laptop so it
On Wed, Oct 03, 2012 at 04:36:53PM +0200, Kay Sievers wrote:
> On Wed, Oct 3, 2012 at 12:12 AM, Greg KH wrote:
>
> > Mauro, what version of udev are you using that is still showing this
> > issue?
> >
> > Kay, didn't you resolve this already? If not, what was the reason why?
>
> It's the same i
On Wed, Oct 3, 2012 at 8:13 AM, Mauro Carvalho Chehab
wrote:
>
> Yes. The issue was noticed with media drivers when people started using the
> drivers on Fedora 17, witch came with udev-182. There's an open
> bugzilla there:
> https://bugzilla.redhat.com/show_bug.cgi?id=827538
Yeah, that
Em 02-10-2012 19:47, Linus Torvalds escreveu:
> On Tue, Oct 2, 2012 at 3:23 PM, Greg KH wrote:
>>
>> which went into udev release 187 which I think corresponds to the place
>> when people started having problems, right Mauro?
>
> According to what I've seen, people started complaining in 182, not
On Wed, Oct 3, 2012 at 7:36 AM, Kay Sievers wrote:
>
> If that unfortunate module_init() lockup can't be solved properly in
> the kernel
Stop this idiocy.
The kernel doesn't have a lockup problem. udev does.
As even you admit, it is *udev* that has the whole serialization
issue, and does exces
On Wed, Oct 3, 2012 at 12:12 AM, Greg KH wrote:
> Mauro, what version of udev are you using that is still showing this
> issue?
>
> Kay, didn't you resolve this already? If not, what was the reason why?
It's the same in the current release, we still haven't wrapped our
head around how to fix it
Em 02-10-2012 19:23, Greg KH escreveu:
> On Tue, Oct 02, 2012 at 03:12:39PM -0700, Greg KH wrote:
>> On Tue, Oct 02, 2012 at 09:33:03AM -0700, Linus Torvalds wrote:
>>> I don't know where the problem started in udev, but the report I saw
>>> was that udev175 was fine, and udev182 was broken, and wo
On Tue, Oct 2, 2012 at 5:01 PM, Jiri Kosina wrote:
> On Tue, 2 Oct 2012, Linus Torvalds wrote:
>
>> And see this email from Kay Sievers that shows that it was all known
>> about and intentional in the udev camp:
>>
>> http://www.spinics.net/lists/netdev/msg185742.html
>
> This seems confusing in
On Tue, 2 Oct 2012, Linus Torvalds wrote:
> And see this email from Kay Sievers that shows that it was all known
> about and intentional in the udev camp:
>
> http://www.spinics.net/lists/netdev/msg185742.html
This seems confusing indeed.
That e-mail referenced above is talking about loading
On Tue, Oct 2, 2012 at 3:23 PM, Greg KH wrote:
>
> which went into udev release 187 which I think corresponds to the place
> when people started having problems, right Mauro?
According to what I've seen, people started complaining in 182, not 187.
See for example
http://patchwork.linuxtv.org/
On Tue, Oct 2, 2012 at 2:03 PM, Ivan Kalvachev wrote:
>
> I'm not kernel developer and probably my opinion would be a little
> naive, but here it is.
>
> Please, make the kernel load firmware from the filesystem on its own.
We probably should do that, not just for firmware, but for modules
too. I
On Tue, Oct 02, 2012 at 03:12:39PM -0700, Greg KH wrote:
> On Tue, Oct 02, 2012 at 09:33:03AM -0700, Linus Torvalds wrote:
> > I don't know where the problem started in udev, but the report I saw
> > was that udev175 was fine, and udev182 was broken, and would deadlock
> > if module_init() did a re
On Tue, Oct 02, 2012 at 09:33:03AM -0700, Linus Torvalds wrote:
> I don't know where the problem started in udev, but the report I saw
> was that udev175 was fine, and udev182 was broken, and would deadlock
> if module_init() did a request_firmware(). That kind of nested
> behavior is absolutely *r
On 10/2/12, Linus Torvalds wrote:
> On Tue, Oct 2, 2012 at 6:03 AM, Mauro Carvalho Chehab
> wrote:
>>
>> I basically tried a few different approaches, including deferred probe(),
>> as you suggested, and request_firmware_async(), as Kay suggested.
>
> Stop this crazy. FIX UDEV ALREADY, DAMMIT.
>
On Tue, Oct 2, 2012 at 6:03 AM, Mauro Carvalho Chehab
wrote:
>
> I basically tried a few different approaches, including deferred probe(),
> as you suggested, and request_firmware_async(), as Kay suggested.
Stop this crazy. FIX UDEV ALREADY, DAMMIT.
Who maintains udev these days? Is it Lennart/K
54 matches
Mail list logo
