Dale Schumacher wrote: > Would such a sharing approach have merit? Or is it an > intellectual/technical dead-end.
That would basically be something like the PC BIOS, which DOS used extensively to communicate with peripherals, the idea being that the hardware makers and DOS developers wouldn't have to share work and/or implementation details. Even in the DOS/Windows world, this model was eventually abandoned because the interface was too inflexible, and Windows eventually just had drivers that talked to the hardware directly. In Linux, hardware makers are strongly encouraged to add their drivers to the operating system. And, of course, that's what we (Openmoko) do. So the whole concept of having a hardware abstraction layer that ships with the hardware, while the operating system is separately maintained and distributed does not apply. Also, with kboot, the kboot kernel and the "real" kernel may very well contain identical drivers, but there's only marginal cost in this duplication (mainly in the driver initialization). If the drivers were to remain active, this would basically mean that the kboot kernel and the "real" kernel would have to have largely identical internal data structures, which goes against the idea of keeping the boot loader comparably stable while changing the kernel whenever desirable. (The idea of having kernels with compatible internals has been tossed around many times for all sorts of cases, but it's basically infeasible to do this, notwithstanding ksplice [1].) [1] http://web.mit.edu/ksplice/ > What do you mean? Are you thinking that the "real" OS would be kept > directly in NAND/NOR flash? What I meant is that we have plenty of space for kboot and that there are also no licensing/marketing constraints that speak against using the full operating system in the boot process. The "real" OS should be kept at a convenient place ;-) On GTA03, that would be an SD card. On GTA02, if actually wanting to convert it to kboot, this could also be an SD card, or NAND. - Werner
