1 |
1275 |
phoenix |
|
2 |
|
|
request_firmware() hotplug interface:
|
3 |
|
|
------------------------------------
|
4 |
|
|
Copyright (C) 2003 Manuel Estrada Sainz
|
5 |
|
|
|
6 |
|
|
Why:
|
7 |
|
|
---
|
8 |
|
|
|
9 |
|
|
Today, the most extended way to use firmware in the Linux kernel is linking
|
10 |
|
|
it statically in a header file. Which has political and technical issues:
|
11 |
|
|
|
12 |
|
|
1) Some firmware is not legal to redistribute.
|
13 |
|
|
2) The firmware occupies memory permanently, even though it often is just
|
14 |
|
|
used once.
|
15 |
|
|
3) Some people, like the Debian crowd, don't consider some firmware free
|
16 |
|
|
enough and remove entire drivers (e.g.: keyspan).
|
17 |
|
|
|
18 |
|
|
about in-kernel persistence:
|
19 |
|
|
---------------------------
|
20 |
|
|
Under some circumstances, as explained below, it would be interesting to keep
|
21 |
|
|
firmware images in non-swappable kernel memory or even in the kernel image
|
22 |
|
|
(probably within initramfs).
|
23 |
|
|
|
24 |
|
|
Note that this functionality has not been implemented.
|
25 |
|
|
|
26 |
|
|
- Why OPTIONAL in-kernel persistence may be a good idea sometimes:
|
27 |
|
|
|
28 |
|
|
- If the device that needs the firmware is needed to access the
|
29 |
|
|
filesystem. When upon some error the device has to be reset and the
|
30 |
|
|
firmware reloaded, it won't be possible to get it from userspace.
|
31 |
|
|
e.g.:
|
32 |
|
|
- A diskless client with a network card that needs firmware.
|
33 |
|
|
- The filesystem is stored in a disk behind an scsi device
|
34 |
|
|
that needs firmware.
|
35 |
|
|
- Replacing buggy DSDT/SSDT ACPI tables on boot.
|
36 |
|
|
Note: this would require the persistent objects to be included
|
37 |
|
|
within the kernel image, probably within initramfs.
|
38 |
|
|
|
39 |
|
|
And the same device can be needed to access the filesystem or not depending
|
40 |
|
|
on the setup, so I think that the choice on what firmware to make
|
41 |
|
|
persistent should be left to userspace.
|
42 |
|
|
|
43 |
|
|
- Why register_firmware()+__init can be useful:
|
44 |
|
|
- For boot devices needing firmware.
|
45 |
|
|
- To make the transition easier:
|
46 |
|
|
The firmware can be declared __init and register_firmware()
|
47 |
|
|
called on module_init. Then the firmware is warranted to be
|
48 |
|
|
there even if "firmware hotplug userspace" is not there yet or
|
49 |
|
|
it doesn't yet provide the needed firmware.
|
50 |
|
|
Once the firmware is widely available in userspace, it can be
|
51 |
|
|
removed from the kernel. Or made optional (CONFIG_.*_FIRMWARE).
|
52 |
|
|
|
53 |
|
|
In either case, if firmware hotplug support is there, it can move the
|
54 |
|
|
firmware out of kernel memory into the real filesystem for later
|
55 |
|
|
usage.
|
56 |
|
|
|
57 |
|
|
Note: If persistence is implemented on top of initramfs,
|
58 |
|
|
register_firmware() may not be appropriate.
|