Moving firmware to userland

[Jan Sucan]

That's good and interesting idea. Attaching the config to the image
could unify the way in which config info is saved for both built-in
and non-built-in images, and also unify a code for parsing the config
info in the kernel firmware subsystem. Possibilities for firmware file
formats:

- uuencoded
   Pros: Config can be added, modified and removed by a text editor
   Cons: .uu files are about 35% larger, need to implement uudecoding in
         the kernel, config correctness checked at firmware loading time

- binary
   Pros: firmware data size, user-interface of the new tool can be
         better suited for given purpose than a text editor (which is too
         general), config correctness checked at config modifying time
   Cons: need to create new tool for handling attached info (something
         like kenv(1) for firmware)

For binary firmware it will be necessary to also add some checksum
data in case when config is not attached and firmware data is also
valid config. Checksum could be computed only from firmware data or it
can cover the config data too.

I think, that the second file format would be better. I can try to
propose a format for the attached config and post it here for a
review.


On Tue, 18 Jul 2017, Sepherosa Ziehau wrote:

> I'd choose plain text config per-image.  BTW, is it possible to attach
> the config at the beginning/end of the image?  Assuming we can force
> some image file creation rules.
>
> On Tue, Jul 11, 2017 at 8:20 PM, Ján Sučan <sucanjan at fit.cvut.cz> wrote:
>> 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
>>
>
>
>
> -- 
> Tomorrow Will Never Die
>
>