* Uwe Hermann uwe@hermann-uwe.de [070424 21:46]:
- have one single prominent place (per mainboard?) for those options?
One place: yes (Kconfig files, for example).
Parts of the settings will be generic, others may be mainboard-specific. But we can still make Kconfig stick them all in the same menu (from a user-perspective) is we want, so that's not a problem.
"One place" is ambiguous. We might prefer all options for a board in one single file, instead of spreading it between lots of Kconfig files.
One method, for sure. But that's what we have already
- inherit options? Options per component? Like superio serial 0/1 on/off should be set in cmos instead of dts or compile time?
Set a default at compile time, but allow overriding via CMOS settings.
Ok, say we add this stuff to Kconfig. How do we get it out of kconfig again, ie. how do we know which Kconfig options are runtime changeable (I hate the word CMOS) options
Not sure what exactly inheriting and per-component options mean here.
per component means: you use a FooBar superio. This allows you to enable/disable serial port 2 at runtime, and at compile time.
inheriting means: where do we get the initial defaults from? If we have per-component settings, the dts is the wrong place for defaults.
- simple format for describing the options
Yes. AFAICS Kconfig can handle everything we have in cmos.layout files now: numbers, strings, multiple-selects (with a default value), etc. etc.
Ok. So each mainboard gets a file Kconfig.options ?
Or will we rather start putting that to northbridge/, southbridge/ and superio/ and try to keep the mainboard/ directory clean per default?
How do you plan to generate a "map" from a Kconfig file, so LinuxBIOS will know where each option sits in the nvram?
- have a tool that creates an "option_table" format file as we have it now, so we can easily use all the existing code for now (get_option(...), linuxbios table, lxbios utility....)
Hm, yes, probably. Needs some more investigations, maybe.
For instance?