* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
[not found] ` <fa.lpiFTa5CtuIkUf2Z5eJ0YlsNwYI@ifi.uio.no>
@ 2012-10-04 14:50 ` Kurt H Maier
2012-10-05 8:03 ` Emmanuel Benisty
0 siblings, 1 reply; 13+ messages in thread
From: Kurt H Maier @ 2012-10-04 14:50 UTC (permalink / raw)
To: linux-kernel
On Wed, Oct 03, 2012 at 07:27:01PM +0000, Al Viro wrote:
>
> Al, that -><- close to volunteering for maintaining that FPOS kernel-side...
>
This would be fantastic.
Kurt H Maier
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-04 14:50 ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Kurt H Maier
@ 2012-10-05 8:03 ` Emmanuel Benisty
2012-10-05 20:17 ` david
0 siblings, 1 reply; 13+ messages in thread
From: Emmanuel Benisty @ 2012-10-05 8:03 UTC (permalink / raw)
To: Kurt H Maier; +Cc: linux-kernel
On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier <khm@sdf.org> wrote:
> On Wed, Oct 03, 2012 at 07:27:01PM +0000, 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 non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.)"
[1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-05 8:03 ` Emmanuel Benisty
@ 2012-10-05 20:17 ` david
2012-10-05 21:43 ` Henrique de Moraes Holschuh
0 siblings, 1 reply; 13+ messages in thread
From: david @ 2012-10-05 20:17 UTC (permalink / raw)
To: Emmanuel Benisty; +Cc: Kurt H Maier, linux-kernel
> On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier <khm@sdf.org> wrote:
>> On Wed, Oct 03, 2012 at 07:27:01PM +0000, 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 non-systemd systems is in our eyes a dead end, in case you
> haven't noticed it yet. I am looking forward to the day when we can drop
> that support entirely.)"
>
> [1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
I think it's worth noting that even though udev 189 was recently released,
the not-yet-released Ubuntu 10.10 is going to be including udev 175.
David Lang
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-05 20:17 ` david
@ 2012-10-05 21:43 ` Henrique de Moraes Holschuh
2012-10-06 19:09 ` udev breakages - Nix
0 siblings, 1 reply; 13+ messages in thread
From: Henrique de Moraes Holschuh @ 2012-10-05 21:43 UTC (permalink / raw)
To: david; +Cc: Emmanuel Benisty, Kurt H Maier, linux-kernel
On Fri, 05 Oct 2012, david@lang.hm wrote:
> >On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier <khm@sdf.org> wrote:
> >>On Wed, Oct 03, 2012 at 07:27:01PM +0000, 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 non-systemd systems is in our eyes a dead end, in case you
> >haven't noticed it yet. I am looking forward to the day when we can drop
> >that support entirely.)"
> >
> >[1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
>
> I think it's worth noting that even though udev 189 was recently
> released, the not-yet-released Ubuntu 10.10 is going to be including
> udev 175.
So is Debian.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages -
2012-10-05 21:43 ` Henrique de Moraes Holschuh
@ 2012-10-06 19:09 ` Nix
0 siblings, 0 replies; 13+ messages in thread
From: Nix @ 2012-10-06 19:09 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: david, Emmanuel Benisty, Kurt H Maier, linux-kernel
On 5 Oct 2012, Henrique de Moraes Holschuh told this:
> On Fri, 05 Oct 2012, david@lang.hm wrote:
>> >On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier <khm@sdf.org> wrote:
>> >>On Wed, Oct 03, 2012 at 07:27:01PM +0000, 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 non-systemd systems is in our eyes a dead end, in case you
>> >haven't noticed it yet. I am looking forward to the day when we can drop
>> >that support entirely.)"
>> >
>> >[1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
>>
>> I think it's worth noting that even though udev 189 was recently
>> released, the not-yet-released Ubuntu 10.10 is going to be including
>> udev 175.
>
> So is Debian.
I'm a bit surprised they didn't stick with 168, really. Even udev 175
requires a /usr mount in the initramfs, and devtmpfs (though the latter
is easy to replace). The former is probably a good idea anyway. The
latter... for any system other than the very largest, or embedded
systems that must boot in a second or less, I can't see a benefit.
--
NULL && (void)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
@ 2012-06-26 1:55 Mauro Carvalho Chehab
2012-10-02 13:03 ` udev breakages - was: " Mauro Carvalho Chehab
0 siblings, 1 reply; 13+ messages in thread
From: Mauro Carvalho Chehab @ 2012-06-26 1:55 UTC (permalink / raw)
To: Greg KH; +Cc: Antti Palosaari, Linux Media Mailing List, Kay Sievers
Em 25-06-2012 19:33, Greg KH escreveu:
> On Mon, Jun 25, 2012 at 05:49:25PM -0300, Mauro Carvalho Chehab wrote:
>> Greg,
>>
>> Basically, the recent changes at request_firmware() exposed an issue that
>> affects all media drivers that use firmware (64 drivers).
>
> What change was that? How did it break anything?
https://bugzilla.redhat.com/show_bug.cgi?id=827538
Basically, userspace changes and some pm-related patches, mainly this one [1]:
@@ -613,7 +606,14 @@ request_firmware(const struct firmware **firmware_p, const char *name,
if (ret <= 0)
return ret;
- ret = _request_firmware(*firmware_p, name, device, true, false);
+ ret = usermodehelper_read_trylock();
+ if (WARN_ON(ret)) {
+ dev_err(device, "firmware: %s will not be loaded\n", name);
+ } else {
+ ret = _request_firmware(*firmware_p, name, device, true, false,
+ firmware_loading_timeout());
+ usermodehelper_read_unlock();
+ }
if (ret)
_request_firmware_cleanup(firmware_p);
[1] at git commit 9b78c1da60b3c62ccdd1509f0902ad19ceaf776b
>> Driver's documentation at Documentation/driver-model/driver.txt says that the
>> .probe() callback should "bind the driver to a given device. That includes
>> verifying that the device is present, that it's a version the driver can handle,
>> that driver data structures can be allocated and initialized, and that any
>> hardware can be initialized".
>
> Yes.
>
>> All media device drivers are complaint with that, returning 0 on success
>> (meaning that the device was successfully probed) or an error otherwise.
>
> Great, no probems then :)
>
>> Almost all media devices are made by a SoC or a RISC CPU that works
>> as a DMA engine and exposes a set of registers to allow I2C access to the
>> device's internal and/or external I2C buses. Part of them have an internal
>> EEPROM/ROM that stores firmware internally at the board, but others require
>> a firmware to be loaded before being able to init/control the device and to
>> export the I2C bus interface.
>>
>> The media handling function is then implemented via a series of I2C devices[1]:
>> - analog video decoders;
>> - TV tuners;
>> - radio tuners;
>> - I2C remote controller decoders;
>> - DVB frontends;
>> - mpeg decoders;
>> - mpeg encoders;
>> - video enhancement devices;
>> ...
>>
>> [1] several media chips have part of those function implemented internally,
>> but almost all require external I2C components to be probed.
>>
>> In order to properly refer to each component, we call the "main" kernel module
>> that talks with the media device via USB/PCI bus is called "bridge driver",
>> and the I2C components are called as "sub-devices".
>>
>> Different vendors use the same bridge driver to work with different sub-devices.
>>
>> It is a .probe()'s task to detect what sub-devices are there inside the board.
>>
>> There are several cases where the vendor switched the sub-devices without
>> changing the PCI ID/USB ID.
>
> Hardware vendors suck, we all know that :(
>
>> So, drivers do things like the code below, inside the .probe() callback:
>>
>> static int check_if_dvb_frontend_is_supported_and_bind()
>> {
>> switch (device_model) {
>> case VENDOR_A_MODEL_1:
>> if (test_and_bind_frontend_1()) /* Doesn't require firmware */
>> return 0;
>> if (test_and_bind_frontend_2()) /* requires firmware "foo" */
>> return 0;
>> if (test_and_bind_frontend_3()) /* requires firmware "bar" */
>> return 0;
>
> Wait, why would these, if they require firmware, not load the firmware
> at this point in time? Why are they saying "all is fine" here?
The above is a prototype of what happens. The "test_and_bind_frontend_n()"
logic are, in fact, more complex than that: it tries to load the firmware
inside each frontend's code when needed.
This is a real example (taken from ttpci budget driver):
switch(budget->dev->pci->subsystem_device) {
case 0x1003: // Hauppauge/TT Nova budget (stv0299/ALPS BSRU6(tsa5059) OR ves1893/ALPS BSRV2(sp5659))
case 0x1013:
// try the ALPS BSRV2 first of all
budget->dvb_frontend = dvb_attach(ves1x93_attach, &alps_bsrv2_config, &budget->i2c_adap);
if (budget->dvb_frontend) {
budget->dvb_frontend->ops.tuner_ops.set_params = alps_bsrv2_tuner_set_params;
budget->dvb_frontend->ops.diseqc_send_master_cmd = budget_diseqc_send_master_cmd;
budget->dvb_frontend->ops.diseqc_send_burst = budget_diseqc_send_burst;
budget->dvb_frontend->ops.set_tone = budget_set_tone;
break;
}
// try the ALPS BSRU6 now
budget->dvb_frontend = dvb_attach(stv0299_attach, &alps_bsru6_config, &budget->i2c_adap);
if (budget->dvb_frontend) {
budget->dvb_frontend->ops.tuner_ops.set_params = alps_bsru6_tuner_set_params;
budget->dvb_frontend->tuner_priv = &budget->i2c_adap;
if (budget->dev->pci->subsystem_device == 0x1003 && diseqc_method == 0) {
budget->dvb_frontend->ops.diseqc_send_master_cmd = budget_diseqc_send_master_cmd;
budget->dvb_frontend->ops.diseqc_send_burst = budget_diseqc_send_burst;
budget->dvb_frontend->ops.set_tone = budget_set_tone;
}
break;
}
break;
>> if (test_and_bind_frontend_4()) /* doesn't require firmware */
>> return 0;
>> break;
>> case VENDOR_A_MODEL_2:
>> /* Analog device - no DVB frontend on it */
>> return 0;
>> ...
>> }
>> return -ENODEV;
>> }
>>
>> On several devices, before being able to register the bus and do the actual
>> probe, the kernel needs to load a firmware.
>
> That's common.
>
>> Also, during the I2C device probing time, firmware may be required, in order
>> to properly expose the device's internal models and their capabilities.
>>
>> For example, drx-k sub-device can have support for either DVB-C or DVB-T or both,
>> depending on the device model. That affects the frontend properties exposed
>> to the user and might affect the bridge driver's initialization task.
>>
>> In practice, a driver like em28xx have a few devices like HVR-930C that require
>> the drx-k sub-device. For those devices, a firmware is required; for other
>> devices, a firmware is not required.
>>
>> What's happening is that newer versions of request_firmware and udev are being
>> more pedantic (for a reason) about not requesting firmwares during module_init
>> or PCI/USB register's probe callback.
>
> It is? What changed to require this? What commit id?
See above.
>> Worse than that, the same device driver may require a firmware or not, depending on
>> the I2C devices inside it. One such example is em28xx: for the great majority of
>> the supported devices, no firmware is needed, but devices like HVR-930C require
>> a firmware, because it uses a frontend that needs firmware.
>>
>> After some discussions, it seems that the best model would be to add an async_probe()
>> callback to be used by devices similar to media ones. The async_probe() should be
>> not probed during the module_init; the probe() will be deferred to happen later,
>> when firmware's usermodehelper_disabled is false, allowing those drivers to load their
>> firmwares if needed.
>>
>> What do you think?
>
> We already have deferred probe() calls, you just need to return a
> different value (can't remember it at the moment), and your probe
> function will be called again at a later time after the rest of the
> devices in the system have been initialized. Can that work for you?
Yeah, I think so. From what I saw, devices that require firmware could do, inside
their probe routine:
if (usermodehelper_disabled)
return -EPROBE_DEFER;
As usermodehelper_disabled is an static symbol at kernel/kmod.c, we would need to
either export it globally or to create a small routine that would return it to
the drivers.
For bridge drivers, a change like that would be trivial. For I2C devices, such change
can be more complex, as the probe() routine will need to be broken into some stages,
one for the bridge driver's core and another one for each I2C device that can be deferred,
keeping a record on what it was deferred, but it seems feasible to me.
Thank you for the suggestion!
> Or, if you "know" you are going to accept this device, just return 0
> from probe() after spawning a workqueue or thread to load the firmware
> properly and do everything else you need to do to initialize. If
> something bad happens, unbind your device with a call to unbind things.
Not sure if this would work, as there are some USB devices with multiple
interfaces and some are handled by other drivers (like mceusb and snd-usb-audio).
IMO, the deferred probe() is the right answer for this issue.
Thanks!
Mauro
^ permalink raw reply [flat|nested] 13+ messages in thread
* udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-06-26 1:55 Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Mauro Carvalho Chehab
@ 2012-10-02 13:03 ` Mauro Carvalho Chehab
2012-10-02 16:33 ` Linus Torvalds
0 siblings, 1 reply; 13+ messages in thread
From: Mauro Carvalho Chehab @ 2012-10-02 13:03 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Linux Kernel Mailing List, Kay Sievers,
Linux Media Mailing List, Michael Krufky
Hi Greg,
Em Mon, 25 Jun 2012 22:55:41 -0300
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> Em 25-06-2012 19:33, Greg KH escreveu:
> > On Mon, Jun 25, 2012 at 05:49:25PM -0300, Mauro Carvalho Chehab wrote:
> >> Greg,
> >>
> >> Basically, the recent changes at request_firmware() exposed an issue that
> >> affects all media drivers that use firmware (64 drivers).
> >
> > What change was that? How did it break anything?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=827538
>
> Basically, userspace changes and some pm-related patches, ...
...
As I pinged you back in June, the recent changes on udev made lots of regression
on all media drivers that require firmware. The news is that the fixes are also
causing more regressions...
Btw, Linus also complained about that:
https://lkml.org/lkml/2012/8/25/136
I basically tried a few different approaches, including deferred probe(),
as you suggested, and request_firmware_async(), as Kay suggested.
The deferred probe() doesn't work as-is, as it will re-probe the driver
only if a new driver is modprobed. It should likely not be that hard to modify
the drivers core to allow it to re-probe after returning the probe status to
udev, but I failed to find a way of doing that (mostly because of the lack of
time, as I'm being too busy those days).
I tried a few other things, like using request_firmware_async() at a few
drivers that require firmware.
That caused a big regression on Kernel 3.6 that we're currently discussing
how to fix, but basically, media devices are very complex, as they have lots
of different blocks there: tuners, analog video demod, digital video demod,
audio demod, etc. On most cases, each of those "extra" blocks are implemented
via I2C, and the device initialization happens serialized.
By letting an I2C driver to do asynchronous initialization, other dependent
drivers broke, because there are some signals used by the other blocks that
are dependent on a proper initialization of a block previously initialized.
One of the specific case is a device very popular in Europe nowadays: the
PCTV 520e. This device uses an em28xx USB bridge chip, a tda18271 i2c tuner
and a drx-k DVB i2c demod (among other things). The DRX-K chipset requires a
firmware; the other chipsets there don't.
The drx-k driver is used in combination with several other drivers, like
em28xx, az6027, xc5000, tda18271, tda18271dd, etc. On my tests, with
the devices I have available (Terratec H5, H6, H7, HTC; Hauppauge HVR 530C),
the usage of request_firmware_async() worked as expected.
So, such patch that made DRX-K firmware load to be deferred were applied at
Kernel 3.6 on this changeset:
commit bd02dbcd008f92135b2c7a92b6
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date: Thu Jun 21 09:36:38 2012 -0300
[media] drxk: change it to use request_firmware_nowait()
The firmware blob may not be available when the driver probes.
Instead of blocking the whole kernel use request_firmware_nowait() and
continue without firmware.
This shouldn't be that bad on drx-k devices, as they all seem to have an
internal firmware. So, only the firmware update will take a little longer
to happen.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It should be noticed that, for the DVB demodulation to work, the DVB demod
should be attached with the tuner module, via this code snippet[1]:
fe = drxk_attach(&pctv_520e_drxk_cfg, &i2c_adap);
tda18271_attach(fe, i2c_tuner_address, &i2c_adap, &pctv_520e_tda18271_cfg);
The evil are in the details: the DRX-K chip produces some clocks needed by
the tuner, and it has some generic GPIO pins that allow to control random
things, with are device-dependent. Also, there is an I2C switch at the board,
used to control I2C access to the tuner: when the switch is off, the tuner is
not visible at the I2C bus[2].
The tda18271 tuner driver needs to read one device register, in order to
identify the chipset version, as there are a few different setups there,
depending if the silicon is version 1 or 2. As this driver doesn't require
any firmware, such read happens at driver's attach time, with should be fine.
Well, before the patch:
1) drxk_attach() would synchronously read the firmware and initialize the
device, setting the needed GPIO pins and clock signals;
2) tda18271_attach() would read the version ID register and initialize the
device.
However, after the patch, drxk_attach() does nothing but filling some internal data
structures and defer the device init job to happen after the firmware load.
So, when tda18271_attach() is called, there wasn't enough time yet to initialize
the DRX-K device. The end result is that the tda18271 version is not identified
and the I2C driver read fails:
tda18271_read_regs: [5-0060|M] ERROR: i2c_transfer returned: -19
Unknown device (16) detected @ 5-0060, device not supported.
Ok, there are lots of ways to fix it, but I suspect that we'll just push the
problem to happen on some place else.
The fact is that coordinating the initialization between the several parts of
those devices is already complex enough when done serialized; doing it
asynchronously will make the initialization code complex and won't bring any
benefit, as the I2C bus will serialize the initialization anyway.
Also, this is just one of the 495 media drivers. Several of them require firmware
during probe() and are currently broken. Fixing all of them will likely require
years of hard work. So, we need to do something else.
For Kernel 3.6, we'll likely apply some quick hack.
However, for 3.7 or 3.8, I think that the better is to revert changeset 177bc7dade38b5
and to stop with udev's insanity of requiring asynchronous firmware load during
device driver initialization. If udev's developers are not willing to do that,
we'll likely need to add something at the drivers core to trick udev for it to
think that the modules got probed before the probe actually happens.
What do you think?
[1] This is a simplified version of the code: I removed a macro and the error
logic from it, to make the code cleaner for reading.
[2] The I2C switch is there to prevent I2C traffic to generate noise that might
interfere at the tuner functions.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-02 13:03 ` udev breakages - was: " Mauro Carvalho Chehab
@ 2012-10-02 16:33 ` Linus Torvalds
2012-10-02 22:12 ` Greg KH
0 siblings, 1 reply; 13+ messages in thread
From: Linus Torvalds @ 2012-10-02 16:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Lennart Poettering
Cc: Greg KH, Linux Kernel Mailing List, Kay Sievers,
Linux Media Mailing List, Michael Krufky
On Tue, Oct 2, 2012 at 6:03 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> 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/Kai, as part of systemd?
Lennart/Kai, fix the udev regression already. Lennart was the one who
brought up kernel ABI regressions at some conference, and if you now
you have the *gall* to break udev in an incompatible manner that
requires basically impossible kernel changes for the kernel to "fix"
the udev interface, I don't know what to say.
"Two-faced lying weasel" would be the most polite thing I could say.
But it almost certainly will involve a lot of cursing.
> However, for 3.7 or 3.8, I think that the better is to revert changeset 177bc7dade38b5
> and to stop with udev's insanity of requiring asynchronous firmware load during
> device driver initialization. If udev's developers are not willing to do that,
> we'll likely need to add something at the drivers core to trick udev for it to
> think that the modules got probed before the probe actually happens.
The fact is, udev made new - and insane - rules that are simply
*invalid*. Modern udev is broken, and needs to be fixed.
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 *required* to work, in order to not cause
idiotic problems for the kernel for no good reason.
What kind of insane udev maintainership do we have? And can we fix it?
Greg, I think you need to step up here too. You were the one who let
udev go. If the new maintainers are causing problems, they need to be
fixed some way.
Linus
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-02 16:33 ` Linus Torvalds
@ 2012-10-02 22:12 ` Greg KH
2012-10-02 22:23 ` Greg KH
0 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2012-10-02 22:12 UTC (permalink / raw)
To: Linus Torvalds, Kay Sievers
Cc: Mauro Carvalho Chehab, Lennart Poettering,
Linux Kernel Mailing List, Kay Sievers, Linux Media Mailing List,
Michael Krufky
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 *required* to work, in order to not cause
> idiotic problems for the kernel for no good reason.
>
> What kind of insane udev maintainership do we have? And can we fix it?
>
> Greg, I think you need to step up here too. You were the one who let
> udev go. If the new maintainers are causing problems, they need to be
> fixed some way.
I've talked about this with Kay in the past (Plumbers conference I
think) and I thought he said it was all fixed in the latest version of
udev so there shouldn't be any problems anymore with this.
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?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-02 22:12 ` Greg KH
@ 2012-10-02 22:23 ` Greg KH
2012-10-02 22:47 ` Linus Torvalds
0 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2012-10-02 22:23 UTC (permalink / raw)
To: Linus Torvalds, Kay Sievers
Cc: Mauro Carvalho Chehab, Lennart Poettering,
Linux Kernel Mailing List, Kay Sievers, Linux Media Mailing List,
Michael Krufky
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 request_firmware(). That kind of nested
> > behavior is absolutely *required* to work, in order to not cause
> > idiotic problems for the kernel for no good reason.
> >
> > What kind of insane udev maintainership do we have? And can we fix it?
> >
> > Greg, I think you need to step up here too. You were the one who let
> > udev go. If the new maintainers are causing problems, they need to be
> > fixed some way.
>
> I've talked about this with Kay in the past (Plumbers conference I
> think) and I thought he said it was all fixed in the latest version of
> udev so there shouldn't be any problems anymore with this.
>
> 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?
Hm, in digging through the udev tree, the only change I found was this
one:
commit 39177382a4f92a834b568d6ae5d750eb2a5a86f9
Author: Kay Sievers <kay@vrfy.org>
Date: Thu Jul 19 12:32:24 2012 +0200
udev: firmware - do not cancel requests in the initrd
diff --git a/src/udev/udev-builtin-firmware.c b/src/udev/udev-builtin-firmware.c
index 56dc8fc..de93d7b 100644
--- a/src/udev/udev-builtin-firmware.c
+++ b/src/udev/udev-builtin-firmware.c
@@ -129,7 +129,13 @@ static int builtin_firmware(struct udev_device *dev, int argc, char *argv[], boo
err = -errno;
} while (err == -ENOENT);
rc = EXIT_FAILURE;
- set_loading(udev, loadpath, "-1");
+ /*
+ * Do not cancel the request in the initrd, the real root might have
+ * the firmware file and the 'coldplug' run in the real root will find
+ * this pending request and fulfill or cancel it.
+ * */
+ if (!in_initrd())
+ set_loading(udev, loadpath, "-1");
goto exit;
}
which went into udev release 187 which I think corresponds to the place
when people started having problems, right Mauro?
If so, Mauro, is the solution just putting the firmware into the initrd?
No wait, it looks like this change was trying to fix the problem where
firmware files were not in the initrd, so it would stick around for the
real root to show up so that they could be loaded. So this looks like
it was fixing firmware loading problems for people?
Kay, am I just looking at the totally wrong place here, and this file in
udev didn't have anything to do with the breakage?
thanks,
greg k-h
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-02 22:23 ` Greg KH
@ 2012-10-02 22:47 ` Linus Torvalds
2012-10-03 15:13 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 13+ messages in thread
From: Linus Torvalds @ 2012-10-02 22:47 UTC (permalink / raw)
To: Greg KH
Cc: Kay Sievers, Mauro Carvalho Chehab, Lennart Poettering,
Linux Kernel Mailing List, Kay Sievers, Linux Media Mailing List,
Michael Krufky
On Tue, Oct 2, 2012 at 3:23 PM, Greg KH <gregkh@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 complaining in 182, not 187.
See for example
http://patchwork.linuxtv.org/patch/13085/
which is a thread where you were involved too..
See also the arch linux thread:
https://bbs.archlinux.org/viewtopic.php?id=134012&p=1
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
There's a possible patch suggested here:
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006357.html
but quite frankly, I am leery of the fact that the udev maintenance
seems to have gone into some "crazy mode" where they have made changes
that were known to be problematic, and are pure and utter stupidity.
Having the module init path load the firmware IS THE SENSIBLE AND
OBVIOUS THING TO DO for many cases. The fact that udev people have
apparently unilaterally decided that it's somehow wrong is scary.
Linus
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-02 22:47 ` Linus Torvalds
@ 2012-10-03 15:13 ` Mauro Carvalho Chehab
2012-10-03 16:38 ` Linus Torvalds
0 siblings, 1 reply; 13+ messages in thread
From: Mauro Carvalho Chehab @ 2012-10-03 15:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Kay Sievers, Lennart Poettering,
Linux Kernel Mailing List, Kay Sievers, Linux Media Mailing List,
Michael Krufky
Em 02-10-2012 19:47, Linus Torvalds escreveu:
> On Tue, Oct 2, 2012 at 3:23 PM, Greg KH <gregkh@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 complaining in 182, not 187.
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
> See for example
>
> http://patchwork.linuxtv.org/patch/13085/
>
> which is a thread where you were involved too..
>
> See also the arch linux thread:
>
> https://bbs.archlinux.org/viewtopic.php?id=134012&p=1
>
> 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
>
> There's a possible patch suggested here:
>
> http://lists.freedesktop.org/archives/systemd-devel/2012-August/006357.html
>
> but quite frankly, I am leery of the fact that the udev maintenance
> seems to have gone into some "crazy mode" where they have made changes
> that were known to be problematic, and are pure and utter stupidity.
>
> Having the module init path load the firmware IS THE SENSIBLE AND
> OBVIOUS THING TO DO for many cases.
Yes, that is the case for most media devices. Some devices can only be
detected as a supported device after the firmware load, as we need the
firmware for the USB (or PCI) bridge to be there, in order to talk with
the media components under the board's internal I2C bus, as sometimes
the same USB/PCI ID is used by boards with different internal components.
> The fact that udev people have
> apparently unilaterally decided that it's somehow wrong is scary.
>
Thanks,
Mauro
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-03 15:13 ` Mauro Carvalho Chehab
@ 2012-10-03 16:38 ` Linus Torvalds
2012-10-03 17:09 ` Al Viro
0 siblings, 1 reply; 13+ messages in thread
From: Linus Torvalds @ 2012-10-03 16:38 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Ming Lei
Cc: Greg KH, Kay Sievers, Lennart Poettering,
Linux Kernel Mailing List, Kay Sievers, Linux Media Mailing List,
Michael Krufky, Ivan Kalvachev
[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]
On Wed, Oct 3, 2012 at 8:13 AM, Mauro Carvalho Chehab
<mchehab@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:
> https://bugzilla.redhat.com/show_bug.cgi?id=827538
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 there may be able to test
it, but it's been open for a long while..
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 has the *potential* to work).
It has a few extra printk's sprinkled in (to show whether it does
anything or not), and it has a few other issues, but it might be worth
testing as a starting point.
We are apparently better off trying to avoid udev like the plague.
Doing something very similar to this for module loading is probably a
good idea too.
I'm adding Ming Lei to the participants too, because hooking into the
firmware loader like this means that the image doesn't get cached.
Which is sad. I'm hoping Ming Lei might be open to trying to fix that.
Hmm?
Linus
[-- Attachment #2: patch.diff --]
[-- Type: application/octet-stream, Size: 2375 bytes --]
drivers/base/firmware_class.c | 59 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 6e210802c37b..2ffcb4030065 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -55,6 +55,54 @@ static bool fw_get_builtin_firmware(struct firmware *fw, const char *name)
return false;
}
+static bool fw_read_file_contents(struct file *file, struct firmware *fw)
+{
+ loff_t size, pos;
+ struct inode *inode = file->f_dentry->d_inode;
+ char *buf;
+
+ if (!S_ISREG(inode->i_mode))
+ return false;
+ size = i_size_read(inode);
+ buf = vmalloc(size);
+ if (!buf)
+ return false;
+ pos = 0;
+ if (vfs_read(file, buf, size, &pos) != size) {
+ vfree(buf);
+ return false;
+ }
+ fw->data = buf;
+ fw->size = size;
+ return true;
+}
+
+static bool fw_get_filesystem_firmware(struct firmware *fw, const char *name)
+{
+ int i;
+ bool success = false;
+ const char *fw_path[] = { "/lib/firmware/update", "/firmware", "/lib/firmware" };
+ char *path = __getname();
+
+printk("Trying to load fw '%s' ", name);
+ for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
+ struct file *file;
+ snprintf(path, PATH_MAX, "%s/%s", fw_path[i], name);
+
+ file = filp_open(path, O_RDONLY, 0);
+ if (IS_ERR(file))
+ continue;
+printk("from file '%s' ", path);
+ success = fw_read_file_contents(file, fw);
+ filp_close(file, NULL);
+ if (success)
+ break;
+ }
+printk(" %s.\n", success ? "Ok" : "failed");
+ __putname(path);
+ return success;
+}
+
static bool fw_is_builtin_firmware(const struct firmware *fw)
{
struct builtin_fw *b_fw;
@@ -346,7 +394,11 @@ static ssize_t firmware_loading_show(struct device *dev,
/* firmware holds the ownership of pages */
static void firmware_free_data(const struct firmware *fw)
{
- WARN_ON(!fw->priv);
+ /* Loaded directly? */
+ if (!fw->priv) {
+ vfree(fw->data);
+ return;
+ }
fw_free_buf(fw->priv);
}
@@ -709,6 +761,11 @@ _request_firmware_prepare(const struct firmware **firmware_p, const char *name,
return NULL;
}
+ if (fw_get_filesystem_firmware(firmware, name)) {
+ dev_dbg(device, "firmware: direct-loading firmware %s\n", name);
+ return NULL;
+ }
+
ret = fw_lookup_and_allocate_buf(name, &fw_cache, &buf);
if (!ret)
fw_priv = fw_create_instance(firmware, name, device,
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-03 16:38 ` Linus Torvalds
@ 2012-10-03 17:09 ` Al Viro
2012-10-03 17:32 ` Linus Torvalds
0 siblings, 1 reply; 13+ messages in thread
From: Al Viro @ 2012-10-03 17:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mauro Carvalho Chehab, Ming Lei, Greg KH, Kay Sievers,
Lennart Poettering, Linux Kernel Mailing List, Kay Sievers,
Linux Media Mailing List, Michael Krufky, Ivan Kalvachev
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 there may be able to test
> it, but it's been open for a long while..
>
> 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 has the *potential* to work).
+ 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.
+ file = filp_open(path, O_RDONLY, 0);
+ if (IS_ERR(file))
+ continue;
+printk("from file '%s' ", path);
+ success = fw_read_file_contents(file, fw);
+ filp_close(file, NULL);
fput(file), please. We have enough misuses of filp_close() as it is...
> We are apparently better off trying to avoid udev like the plague.
> Doing something very similar to this for module loading is probably a
> good idea too.
That, or just adding usr/udev in the kernel git tree and telling the
vertical integrators to go kiss a lamprey...
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-03 17:09 ` Al Viro
@ 2012-10-03 17:32 ` Linus Torvalds
2012-10-03 19:26 ` Al Viro
2012-10-03 19:50 ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Greg KH
0 siblings, 2 replies; 13+ messages in thread
From: Linus Torvalds @ 2012-10-03 17:32 UTC (permalink / raw)
To: Al Viro
Cc: Mauro Carvalho Chehab, Ming Lei, Greg KH, Kay Sievers,
Lennart Poettering, Linux Kernel Mailing List, Kay Sievers,
Linux Media Mailing List, Michael Krufky, Ivan Kalvachev
[-- Attachment #1: Type: text/plain, Size: 714 bytes --]
On Wed, Oct 3, 2012 at 10:09 AM, Al Viro <viro@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 are fucked anyway.
>
> + file = filp_open(path, O_RDONLY, 0);
> + if (IS_ERR(file))
> + continue;
> +printk("from file '%s' ", path);
> + success = fw_read_file_contents(file, fw);
> + filp_close(file, NULL);
>
> fput(file), please. We have enough misuses of filp_close() as it is...
Ok, like this?
Linus
[-- Attachment #2: patch.diff --]
[-- Type: application/octet-stream, Size: 2814 bytes --]
drivers/base/firmware_class.c | 73 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 6e210802c37b..38feac4af991 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -21,6 +21,7 @@
#include <linux/firmware.h>
#include <linux/slab.h>
#include <linux/sched.h>
+#include <linux/file.h>
#include <linux/list.h>
#include <linux/async.h>
#include <linux/pm.h>
@@ -33,6 +34,67 @@ MODULE_AUTHOR("Manuel Estrada Sainz");
MODULE_DESCRIPTION("Multi purpose firmware loading support");
MODULE_LICENSE("GPL");
+/* Don't inline this: 'struct kstat' is biggish */
+static noinline long fw_file_size(struct file *file)
+{
+ struct kstat st;
+ if (vfs_getattr(file->f_path.mnt, file->f_path.dentry, &st))
+ return -1;
+ if (!S_ISREG(st.mode))
+ return -1;
+ if (st.size != (long)st.size)
+ return -1;
+ return st.size;
+}
+
+static bool fw_read_file_contents(struct file *file, struct firmware *fw)
+{
+ loff_t pos;
+ long size;
+ char *buf;
+
+ size = fw_file_size(file);
+ if (size < 0)
+ return false;
+ buf = vmalloc(size);
+ if (!buf)
+ return false;
+ pos = 0;
+ if (vfs_read(file, buf, size, &pos) != size) {
+ vfree(buf);
+ return false;
+ }
+ fw->data = buf;
+ fw->size = size;
+ return true;
+}
+
+static bool fw_get_filesystem_firmware(struct firmware *fw, const char *name)
+{
+ int i;
+ bool success = false;
+ const char *fw_path[] = { "/lib/firmware/update", "/firmware", "/lib/firmware" };
+ char *path = __getname();
+
+printk("Trying to load fw '%s' ", name);
+ for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
+ struct file *file;
+ snprintf(path, PATH_MAX, "%s/%s", fw_path[i], name);
+
+ file = filp_open(path, O_RDONLY, 0);
+ if (IS_ERR(file))
+ continue;
+printk("from file '%s' ", path);
+ success = fw_read_file_contents(file, fw);
+ fput(file);
+ if (success)
+ break;
+ }
+printk(" %s.\n", success ? "Ok" : "failed");
+ __putname(path);
+ return success;
+}
+
/* Builtin firmware support */
#ifdef CONFIG_FW_LOADER
@@ -346,7 +408,11 @@ static ssize_t firmware_loading_show(struct device *dev,
/* firmware holds the ownership of pages */
static void firmware_free_data(const struct firmware *fw)
{
- WARN_ON(!fw->priv);
+ /* Loaded directly? */
+ if (!fw->priv) {
+ vfree(fw->data);
+ return;
+ }
fw_free_buf(fw->priv);
}
@@ -709,6 +775,11 @@ _request_firmware_prepare(const struct firmware **firmware_p, const char *name,
return NULL;
}
+ if (fw_get_filesystem_firmware(firmware, name)) {
+ dev_dbg(device, "firmware: direct-loading firmware %s\n", name);
+ return NULL;
+ }
+
ret = fw_lookup_and_allocate_buf(name, &fw_cache, &buf);
if (!ret)
fw_priv = fw_create_instance(firmware, name, device,
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-03 17:32 ` Linus Torvalds
@ 2012-10-03 19:26 ` Al Viro
2012-10-04 0:57 ` udev breakages - Nix
2012-10-03 19:50 ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Greg KH
1 sibling, 1 reply; 13+ messages in thread
From: Al Viro @ 2012-10-03 19:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mauro Carvalho Chehab, Ming Lei, Greg KH, Kay Sievers,
Lennart Poettering, Linux Kernel Mailing List, Kay Sievers,
Linux Media Mailing List, Michael Krufky, Ivan Kalvachev
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 10:09 AM, Al Viro <viro@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 are fucked anyway.
> >
> > + file = filp_open(path, O_RDONLY, 0);
> > + if (IS_ERR(file))
> > + continue;
> > +printk("from file '%s' ", path);
> > + success = fw_read_file_contents(file, fw);
> > + filp_close(file, NULL);
> >
> > fput(file), please. We have enough misuses of filp_close() as it is...
>
> Ok, like this?
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 volunteering for maintaining that FPOS kernel-side...
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages -
2012-10-03 19:26 ` Al Viro
@ 2012-10-04 0:57 ` Nix
2012-10-04 10:35 ` Nix
0 siblings, 1 reply; 13+ messages in thread
From: Nix @ 2012-10-04 0:57 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Mauro Carvalho Chehab, Ming Lei, Greg KH,
Linux Kernel Mailing List, Kay Sievers, Linux Media Mailing List
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 volunteering for maintaining that FPOS kernel-side...
<flamebait type="heartfelt" subtype="fever-induced">
Please! It has already been forked at least once in userspace by people
who have the temerity to *not use systemd*, imagine that! and still want
a udev that is up-to-date in other ways. (We are now being told that,
contrary to what was said when udev was migrated into the systemd tree,
running udev without systemd is now deprecated and untested and might go
away completely. How surprising, nobody ever predicted that when it
migrated in, oh wait yes we did, and were assured that we were wrong,
that standalone udev would always be supported for those of us who
weren't using systemd. Way to destroy your userbase's trust in you...)
Possibly udev 175, the last standalone udev as far as I know, is a good
place to start from: but you might want to go back a release or two
before that, since 174 was where they started doing insane
backward-compatibility breaks. By 175 they were requiring devtmpfs, no
longer creating device nodes (which I thought was the original *point*
of udev), moving lots of install locations on the assumption that / and
/usr were on the same filesystem, and migrating udevd from /sbin into
/lib/udev without bothering to provide a backward-compatibility symlink.
Net benefit of all this thrashing about to udev users: nil. Net sysadmin
overhead on upgrade: substantial, oh and if you don't do it your system
won't boot.
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 whether our systems would boot every time we upgraded
it, for no discernible benefit. Yes, all the incompatible changes are
(or were, as of udev 175) called out in the release notes -- but there
are so *many* of them, it's easy to miss one. And they all seem so
completely unnecessary, and their implications for your system
configuration grow more and more invasive all the time.
When gregkh was maintaining udev it was nicely robust and kept working
from release to release, and just did its job without requiring us to
change the way our system booted in backwardly-incompatible ways on
every release, merge filesystems together or mount /usr in early boot
(which is SSH-tunneled over a network in the case of one of my systems,
that was fun to do in the initramfs), or install invasive packages that
extend tentacles throughout the entire system, require a complete
rewriting of my boot process and require millions of kernel features
that may not always be turned on.
I'd like those days back. I can trust the kernel people to maintain some
semblance of userspace compatibility between releases, as is crucial for
boot-critical processes. It is now quite clear that I cannot trust the
present udev maintainers, or anyone else involved in the ongoing Linux
desktop trainwreck, to do any such thing.
</flamebait>
--
NULL && (void)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages -
2012-10-04 0:57 ` udev breakages - Nix
@ 2012-10-04 10:35 ` Nix
0 siblings, 0 replies; 13+ messages in thread
From: Nix @ 2012-10-04 10:35 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Mauro Carvalho Chehab, Ming Lei, Greg KH,
Linux Kernel Mailing List, Linux Media Mailing List
[Kay removed because I don't like emailing arguable flamebait directly
to the person flamed.]
On 4 Oct 2012, nix@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 whether our systems would boot every time we upgraded
> it, for no discernible benefit. Yes, all the incompatible changes are
> (or were, as of udev 175) called out in the release notes -- but there
> are so *many* of them, it's easy to miss one. And they all seem so
> completely unnecessary, and their implications for your system
> configuration grow more and more invasive all the time.
In the bright light of day I realize that this post is not as off-topic
for this thread as it appears. This is all of a piece. The udev
maintainer insists that everyone else adapt to udev's demands: before
now, it has been users, sysadmins, and userspace who must adapt, but now
is is pushing its demands in the other direction as well: this thread is
the result.
--
NULL && (void)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-03 17:32 ` Linus Torvalds
2012-10-03 19:26 ` Al Viro
@ 2012-10-03 19:50 ` Greg KH
2012-10-03 20:39 ` Linus Torvalds
1 sibling, 1 reply; 13+ messages in thread
From: Greg KH @ 2012-10-03 19:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: Al Viro, Mauro Carvalho Chehab, Ming Lei, Kay Sievers,
Lennart Poettering, Linux Kernel Mailing List, Kay Sievers,
Linux Media Mailing List, Michael Krufky, Ivan Kalvachev
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 10:09 AM, Al Viro <viro@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 are fucked anyway.
> >
> > + file = filp_open(path, O_RDONLY, 0);
> > + if (IS_ERR(file))
> > + continue;
> > +printk("from file '%s' ", path);
> > + success = fw_read_file_contents(file, fw);
> > + filp_close(file, NULL);
> >
> > fput(file), please. We have enough misuses of filp_close() as it is...
>
> 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.
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-03 19:50 ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Greg KH
@ 2012-10-03 20:39 ` Linus Torvalds
2012-10-03 22:48 ` Andy Walls
0 siblings, 1 reply; 13+ messages in thread
From: Linus Torvalds @ 2012-10-03 20:39 UTC (permalink / raw)
To: Greg KH
Cc: Al Viro, Mauro Carvalho Chehab, Ming Lei, Kay Sievers,
Lennart Poettering, Linux Kernel Mailing List, Kay Sievers,
Linux Media Mailing List, Michael Krufky, Ivan Kalvachev
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH <gregkh@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 been getting more testing in Linux-next or
something, but I suspect that what I'll do is to commit this patch
asap, and then commit another patch that turns off udev firmware
loading entirely for the synchronous firmware loading case.
Why? Just to get more testing, and seeing if there are reports of
breakage. Maybe some udev out there has a different search path (or
because udev runs in a different filesystem namespace or whatever), in
which case running udev as a fallback would otherwise hide the fact
that he direct kernel firmware loading isn't working.
We can (and will) revert things if that turns out to break things, but
I'd like to make any failures of the firmware direct-load path be fast
and hard, so that we can see when/what it breaks.
Ok? Comments?
Linus
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-03 20:39 ` Linus Torvalds
@ 2012-10-03 22:48 ` Andy Walls
2012-10-03 22:58 ` Linus Torvalds
0 siblings, 1 reply; 13+ messages in thread
From: Andy Walls @ 2012-10-03 22:48 UTC (permalink / raw)
To: Linus Torvalds, Greg KH
Cc: Al Viro, Mauro Carvalho Chehab, Ming Lei, Kay Sievers,
Lennart Poettering, Linux Kernel Mailing List, Kay Sievers,
Linux Media Mailing List, Michael Krufky, Ivan Kalvachev
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Wed, Oct 3, 2012 at 12:50 PM, Greg KH <gregkh@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 been getting more testing in Linux-next or
>something, but I suspect that what I'll do is to commit this patch
>asap, and then commit another patch that turns off udev firmware
>loading entirely for the synchronous firmware loading case.
>
>Why? Just to get more testing, and seeing if there are reports of
>breakage. Maybe some udev out there has a different search path (or
>because udev runs in a different filesystem namespace or whatever), in
>which case running udev as a fallback would otherwise hide the fact
>that he direct kernel firmware loading isn't working.
>
>We can (and will) revert things if that turns out to break things, but
>I'd like to make any failures of the firmware direct-load path be fast
>and hard, so that we can see when/what it breaks.
>
>Ok? Comments?
>
> Linus
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media"
>in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
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
Regards,
Andy
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-03 22:48 ` Andy Walls
@ 2012-10-03 22:58 ` Linus Torvalds
2012-10-04 2:39 ` Kay Sievers
0 siblings, 1 reply; 13+ messages in thread
From: Linus Torvalds @ 2012-10-03 22:58 UTC (permalink / raw)
To: Andy Walls
Cc: Greg KH, Al Viro, Mauro Carvalho Chehab, Ming Lei, Kay Sievers,
Lennart Poettering, Linux Kernel Mailing List, Kay Sievers,
Linux Media Mailing List, Michael Krufky, Ivan Kalvachev
On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls <awalls@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. That web doc documents /lib/firmware as being the place to be.
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 hopefully fixes the particular case people see with
media modules.
We definitely want to have configurable paths and a way to configure
udev entirely off for firmware (together with a lack of paths
configuring the direct filesystem loading off - that way people can
set things up just the way they like), but since I'm travelling
tomorrow and this clearly needs more work, I'll do the first step only
for now..
Linus
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
2012-10-03 22:58 ` Linus Torvalds
@ 2012-10-04 2:39 ` Kay Sievers
2012-10-04 17:29 ` udev breakages - Eric W. Biederman
0 siblings, 1 reply; 13+ messages in thread
From: Kay Sievers @ 2012-10-04 2:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andy Walls, Greg KH, Al Viro, Mauro Carvalho Chehab, Ming Lei,
Lennart Poettering, Linux Kernel Mailing List, Kay Sievers,
Linux Media Mailing List, Michael Krufky, Ivan Kalvachev
On Thu, Oct 4, 2012 at 12:58 AM, Linus Torvalds
<torvalds@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
> paths, and that hopefully fixes the particular case people see with
> media modules.
If that approach looks like it works out, please aim for full
in-kernel-*only* support. I would absolutely like to get udev entirely
out of the sick game of firmware loading here. I would welcome if we
are not falling back to the blocking timeouted behaviour again.
The whole story would be contained entirely in the kernel, and we get
rid of the rather fragile "userspace transaction" to execute
module_init(), where the kernel has no idea if userspace is even up to
ever responding to its requests.
There would be no coordination with userspace tools needed, which
sounds like a better fit in the way we develop things with the loosely
coupled kernel <-> udev requirements.
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.
The whole dance with the fake firmware struct device, which has a 60
second timeout to wait for userspace, is a long story of weird
failures at various aspects.
It would not only solve the unfortunate modprobe lockup with
init=/bin/sh we see here, also big servers with an insane amount of
devices happen to run into the 60 sec timeout, because udev, which
runs with 4000-8000 threads in parallel handling things like 30.000
disks is not scheduled in time to fulfill network card firmware
requests. It would be nice if we don't have that arbitrary timeout at
all.
Having any timeout at all to answer the simple question if a file
stored in the rootfs exists, should be a hint that there is something
really wrong with the model that stuff is done.
Thanks,
Kay
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages -
2012-10-04 2:39 ` Kay Sievers
@ 2012-10-04 17:29 ` Eric W. Biederman
2012-10-04 17:42 ` Greg KH
0 siblings, 1 reply; 13+ messages in thread
From: Eric W. Biederman @ 2012-10-04 17:29 UTC (permalink / raw)
To: Kay Sievers
Cc: Linus Torvalds, Andy Walls, Greg KH, Al Viro,
Mauro Carvalho Chehab, Ming Lei, Lennart Poettering,
Linux Kernel Mailing List, Kay Sievers, Linux Media Mailing List,
Michael Krufky, Ivan Kalvachev
Kay Sievers <kay@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 about supporting. Cases that were reported when devtmpfs was
being reviewed.
Additionally the devtmpfs maintainership has not dealt with legitimate
concerns any better than this firmware issue has been dealt with. I
still haven't even hear a productive suggestion back on the hole
/dev/ptmx mess.
As it happens devtmpfs wound up being a userspace process that happens
to reside in the kernel and call mknod. How it makes sense two layers
of messaging and device management instead of just one I don't know.
Certainly I would not crow about that being a success of anything except
passing the buck.
There is debacle written all over the user space interface for dealing
with devices right now.
Eric
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages -
2012-10-04 17:29 ` udev breakages - Eric W. Biederman
@ 2012-10-04 17:42 ` Greg KH
2012-10-04 19:17 ` Alan Cox
2012-10-11 3:32 ` Eric W. Biederman
0 siblings, 2 replies; 13+ messages in thread
From: Greg KH @ 2012-10-04 17:42 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Kay Sievers, Linus Torvalds, Andy Walls, Al Viro,
Mauro Carvalho Chehab, Ming Lei, Lennart Poettering,
Linux Kernel Mailing List, Kay Sievers, Linux Media Mailing List,
Michael Krufky, Ivan Kalvachev
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 maintainership has not dealt with legitimate
> concerns any better than this firmware issue has been dealt with. I
> still haven't even hear a productive suggestion back on the hole
> /dev/ptmx mess.
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.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages -
2012-10-04 17:42 ` Greg KH
@ 2012-10-04 19:17 ` Alan Cox
2012-10-10 3:19 ` Felipe Contreras
2012-10-11 3:32 ` Eric W. Biederman
1 sibling, 1 reply; 13+ messages in thread
From: Alan Cox @ 2012-10-04 19:17 UTC (permalink / raw)
To: Greg KH
Cc: Eric W. Biederman, Kay Sievers, Linus Torvalds, Andy Walls,
Al Viro, Mauro Carvalho Chehab, Ming Lei, Lennart Poettering,
Linux Kernel Mailing List, Kay Sievers, Linux Media Mailing List,
Michael Krufky, Ivan Kalvachev
> 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 for the
userspace folks to handle and if they made it mandatory in their code
diddums, someone better go fork working versions.
Alan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages -
2012-10-04 19:17 ` Alan Cox
@ 2012-10-10 3:19 ` Felipe Contreras
2012-10-10 16:08 ` Geert Uytterhoeven
0 siblings, 1 reply; 13+ messages in thread
From: Felipe Contreras @ 2012-10-10 3:19 UTC (permalink / raw)
To: Alan Cox
Cc: Greg KH, Eric W. Biederman, Kay Sievers, Linus Torvalds,
Andy Walls, Al Viro, Mauro Carvalho Chehab, Ming Lei,
Lennart Poettering, Linux Kernel Mailing List, Kay Sievers,
Linux Media Mailing List, Michael Krufky, Ivan Kalvachev
On Thu, Oct 4, 2012 at 9:17 PM, Alan Cox <alan@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 complaint.
>
> Is it really a problem - devtmpfs is optional. It's a problem for the
> userspace folks to handle and if they made it mandatory in their code
> diddums, someone better go fork working versions.
If only there was a viable alternative to udev.
Distributions are being pushed around by the udev+systemd project
precisely because of this reason; udev maintainers have said that udev
on non-systemd systems is a dead end, so everyone that uses udev
(everyone) is being forced to switch to systemd if they want to
receive proper support, and at some point there might not be even a
choice.
I for one would like an alternative to both systemd and udev on my
Linux systems, and as of yet, I don't know of one.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages -
2012-10-10 3:19 ` Felipe Contreras
@ 2012-10-10 16:08 ` Geert Uytterhoeven
0 siblings, 0 replies; 13+ messages in thread
From: Geert Uytterhoeven @ 2012-10-10 16:08 UTC (permalink / raw)
To: Felipe Contreras
Cc: Alan Cox, Greg KH, Eric W. Biederman, Kay Sievers,
Linus Torvalds, Andy Walls, Al Viro, Mauro Carvalho Chehab,
Ming Lei, Lennart Poettering, Linux Kernel Mailing List,
Kay Sievers, Linux Media Mailing List, Michael Krufky,
Ivan Kalvachev
On Wed, Oct 10, 2012 at 5:19 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Thu, Oct 4, 2012 at 9:17 PM, Alan Cox <alan@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 complaint.
>>
>> Is it really a problem - devtmpfs is optional. It's a problem for the
>> userspace folks to handle and if they made it mandatory in their code
>> diddums, someone better go fork working versions.
>
> If only there was a viable alternative to udev.
>
> Distributions are being pushed around by the udev+systemd project
> precisely because of this reason; udev maintainers have said that udev
> on non-systemd systems is a dead end, so everyone that uses udev
> (everyone) is being forced to switch to systemd if they want to
> receive proper support, and at some point there might not be even a
> choice.
>
> I for one would like an alternative to both systemd and udev on my
> Linux systems, and as of yet, I don't know of one.
A few years ago, the OpenWRT people pointed me to hotplug2 when I mentioned
udev made my poor m68k box with 12 MiB of RAM immediately go OOM.
Don't know if it's suitable for "bigger" machines, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: udev breakages -
2012-10-04 17:42 ` Greg KH
2012-10-04 19:17 ` Alan Cox
@ 2012-10-11 3:32 ` Eric W. Biederman
1 sibling, 0 replies; 13+ messages in thread
From: Eric W. Biederman @ 2012-10-11 3:32 UTC (permalink / raw)
To: Greg KH
Cc: Kay Sievers, Linus Torvalds, Andy Walls, Al Viro,
Mauro Carvalho Chehab, Ming Lei, Lennart Poettering,
Linux Kernel Mailing List, Kay Sievers, Linux Media Mailing List,
Michael Krufky, Ivan Kalvachev
Greg KH <gregkh@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 memory?
Anyone who wants something besides the default policy. Containers
chroots anyone who doesn't want /dev/console to be c 5 1.
>> Additionally the devtmpfs maintainership has not dealt with legitimate
>> concerns any better than this firmware issue has been dealt with. I
>> still haven't even hear a productive suggestion back on the hole
>> /dev/ptmx mess.
>
> 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.
The proposal at that time was to work around the silliness with a little
kernel magic.
To recap for those who haven't watched closely. devpts now has a ptmx
device node and it would be very nice if we were to use that device
node instead of /dev/ptmx.
Baically it would be nice to tell udev to not create /dev/ptmx, and
instead to make /dev/ptmx a symlink to /dev/pts/ptmx.
I got to looking at the problem and if I don't worry about systemd and
just look at older versions of udev that are out there in the wild it
turns out the following udev configuratoin line does exactly what is
needed. It creats a symlink from /dev/ptmx to /dev/pts/ptmx. And if
on the odd chance devpts is not mounted it creates /dev/pts/ptmx as
well.
KERNEL=="ptmx" NAME:="pts/ptmx" SYMLINK="ptmx"
Does assigning to NAME to specify the device naming policy work in
systemd-udev or has that capability been ripped out?
Thinking about it. Since systemd-udev no longer supports changing the
device name. And likely it no longer even supports assigning to NAME
even for purposes of changing the target of the symlink. Then I expect
what we want to do is:
diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
index 147d1a4..7dc5bed 100644
--- a/drivers/base/devtmpfs.c
+++ b/drivers/base/devtmpfs.c
@@ -377,6 +377,7 @@ static int devtmpfsd(void *p)
goto out;
sys_chdir("/.."); /* will traverse into overmounted root */
sys_chroot(".");
+ sys_symlink("pts/ptmx", "ptmx");
complete(&setup_done);
while (1) {
spin_lock(&req_lock);
Eric
^ permalink raw reply related [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-10-11 3:32 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <fa.90I1W/wmSTgRFXVG67o7Pp3+rKA@ifi.uio.no>
[not found] ` <fa.Oszo+r/ZqdTxC2FHqqg+CRVMJ5Y@ifi.uio.no>
[not found] ` <fa.CoxzZZId9dJONv353c+pFG/HO8E@ifi.uio.no>
[not found] ` <fa.ixJ/7D7BnMK8xp7CwikX7jbmnKU@ifi.uio.no>
[not found] ` <fa./ubRQE7P/T+ateohnOKdDxOFhL4@ifi.uio.no>
[not found] ` <fa.lpiFTa5CtuIkUf2Z5eJ0YlsNwYI@ifi.uio.no>
2012-10-04 14:50 ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Kurt H Maier
2012-10-05 8:03 ` Emmanuel Benisty
2012-10-05 20:17 ` david
2012-10-05 21:43 ` Henrique de Moraes Holschuh
2012-10-06 19:09 ` udev breakages - Nix
2012-06-26 1:55 Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Mauro Carvalho Chehab
2012-10-02 13:03 ` udev breakages - was: " Mauro Carvalho Chehab
2012-10-02 16:33 ` Linus Torvalds
2012-10-02 22:12 ` Greg KH
2012-10-02 22:23 ` Greg KH
2012-10-02 22:47 ` Linus Torvalds
2012-10-03 15:13 ` Mauro Carvalho Chehab
2012-10-03 16:38 ` Linus Torvalds
2012-10-03 17:09 ` Al Viro
2012-10-03 17:32 ` Linus Torvalds
2012-10-03 19:26 ` Al Viro
2012-10-04 0:57 ` udev breakages - Nix
2012-10-04 10:35 ` Nix
2012-10-03 19:50 ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Greg KH
2012-10-03 20:39 ` Linus Torvalds
2012-10-03 22:48 ` Andy Walls
2012-10-03 22:58 ` Linus Torvalds
2012-10-04 2:39 ` Kay Sievers
2012-10-04 17:29 ` udev breakages - Eric W. Biederman
2012-10-04 17:42 ` Greg KH
2012-10-04 19:17 ` Alan Cox
2012-10-10 3:19 ` Felipe Contreras
2012-10-10 16:08 ` Geert Uytterhoeven
2012-10-11 3:32 ` Eric W. Biederman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.