Eric W. Biederman wrote: > Tyson D Sawyer <[EMAIL PROTECTED]> writes: > > >>Eric W. Biederman wrote: >> >> >>>Discussion on the linux kernel maillist has reached consensus, on a >>>lot of the design issues. So there is a pretty good chance we will >>>see something in the 2.5 kernel. Assuming I can do a decent >>>implementation... >>>Eric >>> >>> >>I read a thread on a kernel list archive between you and H. Peter Anvin. It all >>left me a bit confused. It seems that he is arguing that the kernel needs to >>call back to the loader to get drivers because you can't load them all with the >>kernel. Isn't the current practice to load all possible drivers for boot >>devices as an initrd? >> > > On the linux booting linux front there is not really any contention. > > On how boot protocols should operate, there is quite a bit of > contention. A crude summary: > > H. Peter Anvin x86 BIOS good. > Eric Biederman x86 BIOS bad. > > Where the missing pieces come from is that with the upcoming initramfs > a bootloader can build the cpio archive (from which the initramfs is > populated) on the fly. In which case there is some advantage on > memory starved machines to only load those modules into the initramfs > that are actually present, on the machine. For ELF images they can be > extended without a huge lot of effort to be able to delete the unused > modules (which is just as good). > > But you are right none of that reflects current practice, but instead > what may become current practice at the end of this kernel development > cycle. > > Personally I don't think it is a big deal to support having every > hardware driver loaded, because amounts of memory increase > exponentially while the amount of drivers appears to increase > linearly. But at the same time it is worth thinking about.
I wouldn't be too quick to understate the value of small. My system happens to have plenty of FLASH, RAM and disk space, but many don't. Small is almost always a virtue for embedded applications and linux has a big future in small devices. The good news is that most embedded apps don't guess at what hardware they are using. How is the cpio archive given to the kernel? Does it differ much from a compressed initrd? What options are there for setting kernel command line options on boot time using the ELF mechanism? It would seem that using a standardized ELF kernel loading mechanism doesn't have to be incompatible with a cpio archive for populating an initramfs. Load the ELF kernel, load the cpio image, pass the kernel any needed args and jump to it. This doesn't seem radically different from the kernel finding other resources while initializing. The cpio archive is just an other resource in the system that the kernel uses. Ty -- Tyson D Sawyer iRobot Corporation Senior Systems Engineer Military Systems Division [EMAIL PROTECTED] Robots for the Real World 603-532-6900 ext 206 http://www.irobot.com
