Re: Class device namespaces

[Kay Sievers <kay.sievers@vrfy.org>]

On Thu, Apr 30, 2009 at 17:18, David Dillow <dave@thedillows.org> wrote:
> On Wed, 2009-04-29 at 23:53 +0200, Kay Sievers wrote:
>> On Wed, Apr 29, 2009 at 23:28, Michael Brown <mebrown@michaels-house.net> wrote:
>> > I cant say that I've ever seen any problems due to udev
>> > cancelling a firmware request.  In fact, if I manually trigger a
>> > request using "echo" from the cmdline, I dont see udev take any action
>> > with the dell_rbu device. eg (Fedora 10, udev-127-5.fc10):
>>
>> If you run:
>>   udevmonitor --udev --env
>> at the same time, what does it say?
>>
>> > I dont see any of the behaviour that you have talked about. If I let
>> > it sit there for hours, it will stay at that state. It only closes up
>> > the request_firmware() request when I echo 0 > loading.
>>
>> Udev will run in the moment this sysfs device is created, and it
>> should trigger the removal of the device, if it does not find the
>> requested firmware file.
>
> drivers/firmware/dell_rbu.c does this:
> req_firm_rc = request_firmware_nowait(THIS_MODULE,
>                                FW_ACTION_NOHOTPLUG, "dell_rbu",
>                                &rbu_device->dev, &context,
>                                callbackfn_rbu);
>
> I've not gone looking to verify, but FW_ACTION_NOHOTPLUG implies to me
> that udev never sees a uevent for it.

Ah, I see. Pretty weird idea to do that with polling, should be better
some key that tells udev to ignore the event, and you could listen to
the events yourself, instead of checking for them in sysfs at a
specific path and fixed name. But looks fine:
  if (uevent)
    dev_set_uevent_suppress(f_dev, 0);

Thanks,
Kay