Moving firmware to userland

[Sepherosa Ziehau]

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