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 <sucan...@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
