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
On 10/02/2012 06:37 PM, Linus Torvalds wrote:
On Tue, Oct 2, 2012 at 2:03 PM, Ivan Kalvachev ikalvac...@gmail.com 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
On Fri, Oct 12, 2012 at 2:33 AM, Shea Levy s...@shealevy.com 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
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
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
On Wed, Oct 10, 2012 at 5:19 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Oct 4, 2012 at 9:17 PM, Alan Cox a...@lxorguk.ukuu.org.uk 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
Greg KH gre...@linuxfoundation.org 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
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
On Thu, Oct 4, 2012 at 9:17 PM, Alan Cox a...@lxorguk.ukuu.org.uk 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
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
>>
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 k...@sdf.org wrote:
On Wed, Oct 03, 2012 at 07:27:01PM +, Al Viro wrote:
Al, that -- close to volunteering for maintaining that FPOS
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
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
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:
On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier k...@sdf.org 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:
On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier k...@sdf.org 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:
On Fri, 05 Oct 2012, da...@lang.hm wrote:
On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier k...@sdf.org 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
> 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
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
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
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
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
>>
>>
[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
[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
On Wed, Oct 3, 2012 at 6:58 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls awa...@md.metrocast.net wrote:
I don't know if you can remove the /sys/.../firmware ABI altogether, because
there is at least one, somewhat popular udev replacement
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 that
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 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
Kay Sievers k...@vrfy.org 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
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
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 problem
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
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
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 -><-
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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",
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
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
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,
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
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
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
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 would
On Wed, Oct 3, 2012 at 12:12 AM, Greg KH gre...@linuxfoundation.org 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
On Wed, Oct 3, 2012 at 7:36 AM, Kay Sievers k...@vrfy.org 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
Em 02-10-2012 19:47, Linus Torvalds escreveu:
On Tue, Oct 2, 2012 at 3:23 PM, Greg KH gre...@linuxfoundation.org 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
On Wed, Oct 3, 2012 at 8:13 AM, Mauro Carvalho Chehab
mche...@redhat.com 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:
On Wed, Oct 03, 2012 at 04:36:53PM +0200, Kay Sievers wrote:
On Wed, Oct 3, 2012 at 12:12 AM, Greg KH gre...@linuxfoundation.org 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?
On Wed, Oct 3, 2012 at 9:38 AM, Linus Torvalds
torva...@linux-foundation.org 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
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 reporter
On Wed, Oct 3, 2012 at 6:57 PM, Greg KH gre...@linuxfoundation.org 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
On Wed, Oct 3, 2012 at 10:09 AM, Al Viro v...@zeniv.linux.org.uk 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
On Wed, Oct 3, 2012 at 10:24 AM, Kay Sievers k...@vrfy.org 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
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
On Wed, Oct 3, 2012 at 10:09 AM, Al Viro v...@zeniv.linux.org.uk wrote:
+ if (!S_ISREG(inode-i_mode))
+ return false;
+ size = i_size_read(inode);
Probably better to do vfs_getattr() and check
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 gre...@linuxfoundation.org wrote:
Mauro, what version of udev are you using that is still showing this
issue?
Kay, didn't you resolve this already?
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
On Wed, Oct 3, 2012 at 10:09 AM, Al Viro v...@zeniv.linux.org.uk wrote:
+ if (!S_ISREG(inode-i_mode))
+ return false;
+ size = i_size_read(inode);
Probably better to do vfs_getattr() and check
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH gre...@linuxfoundation.org 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
On Wed, Oct 3, 2012 at 10:39 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH gre...@linuxfoundation.org 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
On Wed, Oct 03, 2012 at 01:39:23PM -0700, Linus Torvalds wrote:
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH gre...@linuxfoundation.org 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
Greg KH gre...@linuxfoundation.org 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 v...@zeniv.linux.org.uk
wrote:
+ if (!S_ISREG(inode-i_mode))
+ return false;
+ size = i_size_read(inode);
On Wed, Oct 3, 2012 at 11:05 PM, Greg KH gre...@linuxfoundation.org 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
On Wed, 3 Oct 2012 23:18:06 +0200
Kay Sievers k...@vrfy.org wrote:
On Wed, Oct 3, 2012 at 11:05 PM, Greg KH gre...@linuxfoundation.org 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
On Wed, Oct 3, 2012 at 5:39 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH gre...@linuxfoundation.org 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
On Tue, Oct 2, 2012 at 7:37 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Oct 2, 2012 at 2:03 PM, Ivan Kalvachev ikalvac...@gmail.com 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
On Wed, Oct 3, 2012 at 2:58 PM, Lucas De Marchi
lucas.de.mar...@gmail.com 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
Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH gre...@linuxfoundation.org
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
Hi Linus,
On Wed, 3 Oct 2012 13:39:23 -0700 Linus Torvalds
torva...@linux-foundation.org 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
On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls awa...@md.metrocast.net 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.
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 -- close to
On Wed, Oct 3, 2012 at 6:33 PM, Ming Lei ming@canonical.com 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
On Thu, Oct 4, 2012 at 12:58 AM, Linus Torvalds
torva...@linux-foundation.org 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
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
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
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.
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
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
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
1 - 100 of 110 matches
Mail list logo
