Moving firmware to userland

Ján Sučan sucanjan at fit.cvut.cz
Tue Jul 11 05:20:05 PDT 2017


Hello,

I would like to introduce a few ideas about the new firmware subsystem. 
I assume that it should not require adding a new system tools or 
modifying boot process.

Simplification is the first. It would be good to remove parent-child 
relationship and corresponding functionality. It would significantly 
simplify firmware handling. Its only practical use is when there are 
multiple images in one loadable kernel module. The module can be 
unloaded when all children are not in use. Usage of the children images 
is tracked through the counter for the parent image. If images will not 
be placed inside loadable kernel modules, the parent-child mechanism 
won't have any practical meaning. I think, currently the mechanism is 
not used anywhere in the DragonFly system and if it was, it could be 
easily replaced by putting every child image in its own module without 
modifying drivers.

There are two use cases according to who will provide firmware images to 
the system:

- developers of DragonFly BSD (they can modify and rebuild the system)
- third-parties (they should not be required to modify and rebuild the 
system)

Providing a new non-built-in firmware should not require:

a) system rebuild
b) system reboot
c) loading a kernel module

All firmware images needs to have some information attached (at least, 
if ack with a license is needed) which should be

d) stored persistently.

The question is where to save the information for non-built-in images. 
For built-in images the info is saved in the kernel. Some possibilities 
are:

- A plain text configuration file per image.
   This satisfies requirements a), b), c) and d). Disadvantage is 
parsing the text content.

- Kernel environment variables.
   The problem with this is that they are initialized:
     - by some kernel code (this violates a), b), c) )
     - manually from userland by kenv command or kenv() libc function 
(violates d) )
     - in the loader.conf (violates b) since the content is processed at 
boot time)
   Advantage is that the parsing is done by the kernel.

There would be two firmware sources: kernel and filesystem. In case of 
the same image names, user could have a choice by setting a kernel 
environment variable, firmware from which source has higher priority and 
will be provided to consumer.


I will be happy for a comments and ideas
jan



More information about the Kernel mailing list