Stefan Reinauer wrote: > Al Boldi wrote: > > The problem with the current tiny-kernel approach is that, it can't get > > nearly as tiny as filo. And when you have legacy systems like i440bx > > with only 256kb flash, then tiny-kernel becomes a definite no go, which > > make filo the only viable solution. > > > > What we really need is a stripped down tiny-kernel. IOW, a single-proc > > kernel-stub with its sole purpose to provide access to the large linux > > driver pool. Later, this could conceivably be inlined with the > > LinuxBIOS code-base, making LinuxBIOS really a BIOS that makes use of > > linux. > > I don't have good memories on this approach: MILO, the Alpha Linux > bootloader, did exactly that. Been there, done that. I made such a stub > for Kernels 2.2 and 2.4.
How big did the stub turn out to be? > The one disadvantage of all Linux as Bootloader approaches is that you > can not really fit any decent amount of drivers into any existing system > flash. Yes it has been done as a proof-of-concept but as far as I know > Linux-as-bootloader never made it into any product (that I know of) > > Ripping the scheduler out of Linux will get us space for another half to > full driver ... But creating a flexible ROM that allows to use all SCSI > controllers and boot a number of operating systems, will always fail. > The SCSI drivers of Linux alone are more than 30MByte. Even with 128MBit > parts we don't come anywhere close. You wouldn't want to compile all drivers in. Just the ones to boot the system, and then kexec the real kernel. > Don't get me wrong. I do like the L-A-B approach. It's just not the > solution to all problems. Agreed. Thanks! -- Al -- linuxbios mailing list [email protected] http://www.linuxbios.org/mailman/listinfo/linuxbios
