[LinuxBIOS] v3(?) config [was:changes in decompress coming.]

[Peter Stuge]

On Fri, Sep 15, 2006 at 06:56:36PM -0600, ron minnich wrote:
> OK, I'd like to propose a challenge for the outcome of the
> linuxbios summit. I think this is doable. The challenge is simple.

Hehe, we're all eager. :)

Some of my thoughts, from the user's perspective:

* Ridiculous and error-prone to require commands in three dirs for a
build. (Edit targets/foo/bar/Config.lb, run ./buildtarget foo/bar in
targets and finally cd targets/foo/bar/baz to make.)
(Deps fail on reconfig, I've gotten the wrong payload a couple of
times causing annoying extra reboots/hotswaps/flashes.)

* Flash ROM size needs to affect one option, and one option only.
Maybe even autodetect it for those building on the target. All other
sizes can and MUST be derived from this value.
Also: What about option ROMs? Should we aim to produce a ready-to-use
lb-2.0-epia.rom and require a correct (how carefully do we check?)
vgabios.rom in order to build with VGA support - or just dump a half-
finished product in the user's lap and require them to finish the
puzzle on their own? Licensing issues? Is "cat" considered "linking"?

* Any redundancy in the config/build process should be removed. I
must not need to type the target name more than once. Brings me
to..

* Global vs. local builds - pros/cons with kernel style (global)
build (always produces arch/x/*Image) and LBv2 style build (produces
target/x/y/z/linuxbios.rom for each target) Either way the
config/build system must be consistently either global or local.

* Support for target variants? Same mobo with/without certain parts
populated. Perhaps just sets of default options that can be
pre-selected as a base config and then still allow user to change
whatever they want. (Kconfig has just one variant per arch, right?)

..basically we want a system that is able to do very complex detailed
configurations but that's also able to hide all the details behind
"512KiB EPIA-MII 6000E without CF addon" (hypothetical example)

Some boards will require more from the user, but when possible a
config and build should be dirt simple.

One idea is a kind of iterative config with increasing resolution per
iteration. Novice users with a known-good board need only complete
the first iteration: flash size, board name and board variant if any.
Further iterations are optional and allow increasingly specific
settings. Think fdisk normal/expert mode.

* Payload. I say something must be included in the LB tree or
trivially added to a tree by download or command. FILO is candidate
for inclusion.
What's up with FILO(EB) and FILO(LB) ? Merge them? Make EB default
payload? FILO? memtest86? All about making a usable product.
memtest86 would have to be explicitly selected in expert mode in
favor of the default option that would be able to load an OS. Doesn't
matter much if it's only Linux right now because that's the most
likely boot candidate for early LB adopters.

* Payload config. Long/tedious for EB, simple default for boards with
onboard LAN, what to do otherwise? Tricky for FILO.
(e.g. EPIA-MII CF boot requires IDE+!PCI, !PCI requires !USB or build
fails) filesystems, devices, etc.

* Kernel payload and payload utilities - where to get mkelfImage? I
had to look hard. Should it be downloaded on demand? Perhaps after
the user chooses her payload? Think cygwin installer that downloads
selected packages. Maybe a bad idea.

* Consistent terminology - the payload seems to have many names in
the decompression code. ;)


Don't flame me too hard.


//Peter