Hi all,
After the feedback on fwfs, here is my new attempt to move the firmware
to userspace.
This time there is working hotplug functionality including preliminary
firmware.* hotplug scripts.
Attached goes the README and sample driver code for easy inspection and
a full tarball for testing.
Have a nice day
Manuel
--
--- Manuel Estrada Sainz <ranty@debian.org>
<ranty@bigfoot.com>
<ranty@users.sourceforge.net>
------------------------ <manuel.estrada@hispalinux.es> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.
request_firmware() hotplug interface: ------------------------------------
This is not finished code, but most of the functionality is already there.
Why: ---
Today, the most extended way to use firmware in the Linux kernel is linking it statically in a header file. Which has political and technical issues:
1) Some firmware is not legal to redistribute. 2) The firmware occupies memory permanently, even though it often is just used once. 3) Some people, like the Debian crowd, don't consider some firmware free enough and remove entire drivers (e.g.: keyspan).
What: ----
My current plan consists on implementing two pieces:
1) A simple interface for drivers to ask for a named piece of firmware via hotplug. 2) A default way to get the firmware from user space into a [virtually] contiguous memory buffer for drivers to use with ease. - Currently fwfs
Drivers should be able to use 1) without using 2) as shown in firmware_sample_driver.c. In that case arrangements should be made for hotplug scripts to do the firmware load by themselves either via sysfs or some way else. As much information as possible should be set on the environment so hotplug scripts can do the job when 1) is used without 2). Currently just an string provided by the driver is set as 'DEVICE'. Once ported to 2.5 'struct device' can be used instead and more information will be available.
Notes: -----
- Even though the Makefile has 2.5 support the code does not. I'll port it once we agree on how all this should be done.
- Why I don't think any more that sysfs is good as "the default" for userspace to provide the firmware: - For drivers providing a sysfs entry for firmware: It will be trivial to use request_firmware() and arrange the hotplug scripts to get it copied to their sysfs firmware entry. They don't need any additional support for copying the firmware from userspace. - For drivers not providing a sysfs entry for firmware: They just want the appropriate firmware in a memory buffer. It doesn't make much sense to hack some code to get a sysfs entry for them and then tell hotplug where to copy the firmware. The driver won't know that the entry is there, and it won't make sense to write data to it unless requested via hotplug.
If fwfs is finally not found appropriate, I think that a simpler more specific implementation should be better. - Why OPTIONALLY caching the firmware in-kernel may be a good idea sometimes: - If the device that needs the firmware is needed to access the filesystem. When upon some error the device has to be reset and the firmware reloaded, it won't be possible to get it from userspace. e.g.: - A diskless client with a network card that needs firmware. - The filesystem is stored in a disk behind an scsi device that needs firmware. - On embedded systems (like install floppies) where there is no userspace hotplug support, 'cp firmware_file /firmware/' can be handy. And the same device can be needed to access the filesystem or not depending on the setup, so I think that the choice on what firmware to cache should be left to userspace.
- Why register_firmware()+__init can be useful: - For boot devices needing firmware. - To make the transition easier: The firmware can be declared __init and register_firmware() called on module_init. Then the firmware is warranted to be there even if "firmware hotplug userspace" is not there jet or it doesn't jet provide the needed firmware. Once the firmware is widely available in userspace, it can be removed from the kernel. Or made optional (CONFIG_.*_FIRMWARE).
In either case, if firmware hotplug support is there, it can move the firmware out of kernel memory into the real filesystem for later usage (like the provided hotplug scripts do).
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:14 EST