Re: Test-DFS for PowerPC
On Mon, Jun 07, 2004 at 05:06:27PM +0200, Sven Luther wrote:
> reimplementation using the discover database), as the debian-installer
Well, the purposes of DFS and of debian-installer are a little
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
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?