Re: Runaway loop with the current git.

From: Evgeniy Polyakov
Date: Sun Dec 07 2008 - 12:14:28 EST


On Sun, Dec 07, 2008 at 05:01:08PM +0000, Alan Cox (alan@xxxxxxxxxxxxxxxxxxx) wrote:
> > Wrong. First at least because tty/console stuff is built in.
>
> Are you two people or just two names and email addresses for
> the same ?

Depending on who you are asking for.

> /dev/console is a logical mapping to a device which may well be
> different, loaded after PCI is initialised and dependant on PCI.

Yup. It may. But in showed case it is not. In showed case it showed a
bug. Which you call a feature.

> > But we alredy got, that you decided that Debian's initramfs-tools (0.92e)
> > are allowed not to boot with some kernel configs.
>
> Yes. They won't boot if you don't include any disk drivers. They won't
> boot if you don't include any file systems. They wont boot in a million
> other cases. That is the user space not the kernel at fault.

But right now _everything_ is presented. All things are in places.
Disk drivers, filesystem, and even that stupid console/tty driver.
It _IS_ in the kernel.

> The kernel is doing precisely what it is supposed to. It is even logging
> the user space bug and stopping trying to get stuck in a loop loading a
> module in order to attempt to cope with the user space bug.
>
> If you want to complain then file a debian bug, go fix the user space.

You introduce so naive rules for the initramfs userspace... It should
not use console, it should not load modules, which may load another
one... What next, not to use syscalls? Sigh, instead of thinking on how
to fix the weak boot process so that next time similar problem arises,
we ended up with pointing a finger one to another... Hope we will not
get another similar cases though.

--
Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/