Re: Class device namespaces

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

On Wed, Apr 29, 2009 at 23:28, Michael Brown <mebrown@michaels-house.net> wrote:
> On Wed, Apr 29, 2009 at 2:10 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> Udev runs exactly at the time you create the device, and is not
>> unlikely faster than your polling, at least not predictable slower.
>> And it will cancel all requests which can not be fulfilled by udev
>> itself.
>>
>> I strongly recommend switching to a different solution, you can not
>> use the firmware_class interface on any udev system, the interface is
>> already taken, and it's a single-user interface the way it is
>> implemented today. That it seems to work for you, is pure luck, I
>> guess. :)
>
> Is there a safe/easy way to tell udev that we will handle a particular
> request?

No, not with the current interface.

> 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.

> At this point, we have had this interface in the upstream kernel.org
> kernel since 2.6.14 and have a pretty huge legacy codebase that relies
> on this behaviour. We need to make sure that the current behaviour
> remains.

If we are talking about the same thing, which I'm not really sure
anymore, then you can not be sure that this will work in the future.
You can not reliably take over requests for the firmware class with
custom tools while udev is running.

Kay