On Mon, Jun 07, 2004 at 05:06:27PM +0200, Sven Luther wrote: > reimplementation using the discover database), as the debian-installer > does.
Well, the purposes of DFS and of debian-installer are a little different. DFS explicitly does *not* do hardware autodetection on boot, though it prints out a message on boot telling the user how to run discover or hotplug. The reason is that, as a recovery tool, you may not want to attempt this discovery (and that could especially be the case if, for instance, your network controller is fried and the kernel hangs trying to bring it up). Another goal is to make the kernel be one that somebody can slap onto their hard disk in an emergency and be able to boot from their hard disk again. I actually initially was going to not use modules at all to make it easier, but when I realized that some Ethernet module's probing code hangs machines, I abandoned that course :-) However, I still think that mkinitrd or some such solution is too complex and error-prone for this use. The stock Debian kernels are unsuitable for a number of reasons. One is that they do not have enough filesystems, LVM/RAID, etc. compiled in, so they are unsuitable for emergency use in a lot of situations (requiring an initrd just to be able to grok the root fs in these cases). I am not terribly troubled by a 5MB kernel size for this application, actually. I don't know a lot about PowerPC subarchs, but on Alpha we do have subarchs but can compile a "generic" kernel that runs everywhere, which is what I have done. I'm not all that concerned, in general, about running on machines old enough that they can't run a 5MB kernel and bash at the same time. DFS kernels also omit things that are not necessary for installation/repair work. For instance, sound and video4linux are completely disabled. The DFS kernels are here to give people a live, working system to use to repair or install Debian and build a custom kernel from there. > Actually, i believe that the initrd of the default debian kernel should > use discover too, and not the non-robust mess that is produced by > mkinitrd right now. And then, having an ocaml reimplementation of Yes, mkinitrd mostly sucks. OTOH neither discover nor hotplug are complete solutions. Both miss certain hardware. > If ytou don't do that, and which to support more than just the subarches > that are most common, you will need to do agiant kernel like we did for > 2.4.25 (the debian kernel is over 5Mo big i believe). Can you clarify how the powerpc subarchs work so I can get a better understanding of the problem? Is it possible to compile a kernel that runs on all subarchs? Thanks, John
