[LinuxBIOS] lxbios bug?

Stefan Reinauer stepan at coresystems.de
Tue Apr 24 01:00:45 CEST 2007

* ron minnich <rminnich at gmail.com> [070424 00:50]:
> Hi, I've thought hard about the "one single place" for V3 config, and
> I am thinking we will always have 2 files that define configuration,
> like it or not. There will always be some things in Kconfig, and some
> things in DTS. DTS describes, for the most part, data structures used
> at runtime. 

... how does the machine look

> Kconfig, for the most part, defines how to build
> linuxbios. But in Kconfig there are a very small number of things
> related to runtime

... configuration stuff. serial console? usb console? ... compile time
options for those.

>  -- CMOS options being one of them, we hope, And in
> DTS there may be things related to how to build linuxbios (Although I
> can't think of one at present).

runtime configuration.

We basically have three now. We might marry options with options. But we
should not try to marry hardware description and options. Even though we
called it config in v2, it really is more than that. 

> There is some small overlap. I think there always may be. We should
> work to minimize the overlap, but not go too crazy if we can't remove
> it all.

In a perfect world, we would only have runtime configurable options

- because flashes would be big enough to hold all compile time options
- because we could autodetect everything.

> Just a meta-thought on the Kconfig vs. DTS discussion.

I completely agree. Overlap is less ugly when the concept is nice, and
when we don't spaghetti it up to a max. 

Those things are different information entities:
1) hw description
2) compile time config (image description)
3) run time settings (user environment "description")

We can mix those at will by making them a single file, or we can make
three files, or two out of it. If we can unite any and things will
become easier without dropping flexibility, that's great. But we need to
be careful and choose the tools after we found a suitable set of
requirements/features of why we are doing it. (Like, if we are never
ever going to disable IOMMU, why add an option to do so, bad example[tm])


coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/

More information about the coreboot mailing list