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