Moving firmware to userland

[Sepherosa Ziehau]

Hi,

On Wed, Jul 19, 2017 at 4:27 PM, Jan Sucan <sucanjan at fit.cvut.cz> wrote:
> 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.

Yeah, sure, go ahead :)

Thank you,
sephe

>
>
>
> 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
>>
>



-- 
Tomorrow Will Never Die