[coreboot] Kconfig vs. devicetree vs. CMOS policy for options?

[Patrick Georgi]

Am 16.05.2011 01:42, schrieb Peter Stuge:
> Talking to a lot of visitors at LinuxTag it is absolutely clear that
> this is an example of what should actually be an NVRAM option.
> 
> Do we have some policy for where to place an option? I don't think we
> do. Do we want to create one?
My idea for a long term plan:
- move most stuff to NVRAM
- allow defaults in NVRAM config (per chip component)
- allow boards to override these defaults
- allow boards to lock down options (so they're compiled out in our code
and present as "hard coded values" in cbtable)
- probably/eventually: allow user to change defaults/lock them down in
Kconfig

That way we can make everything flexible, yet lock down options that
make no sense (eg. disable IDE/SATA option on boards with IDE function
on chip but no connector on board).
The hard part will be (again) how to extend Kconfig, and I guess this
will require automatic Kconfig file creation (ie. Makefile magic).
But since this is the last step (right after Infrastructure
Projects/CMOS), this can wait.


Patrick