Subject: Re: Runaway loop with the current git.
Date: Tuesday 9th December 2008 01:09:37 UTC (over 8 years ago)
On Mon, Dec 08, 2008 at 04:35:20AM +0100, Kay Sievers wrote: > Sure, if we can make userspace behave nicely, I'm all for doing it. On > the other hand, I think it's a good thing to provide a sane > environment by the kernel for any "non-initramfs-optimized" helper. > Writing to /dev/console is a usual behavior for tools used in > initramfs, to be able to debug bootup problems. In many cases it is > just glibc's fallback LOG_CONS, if syslog is not available. Well, can we agree that (a) there is a generalized modprobe recursion detector already in the kernel, and (b) for some reason, Debian isn't triggering it? That seems like a bug, and while it may not be 100% clear whether the bug is on the userspace side or the kernel side, it would seem that finding and fixing *that* would be a Good Thing, and it could be argued that a specific don't request char-major-5-1 would be papering over this bug (whether it is in Debian's initrd or in the kernel side code). It would be good to make sure we understand what the root causes for while the modprobe recursion detector is apparently not triggering, since it could be that Debian's initrd might cause some other uncaught recursion loop if we don't drive this problem determination to root cause. > That's why I still think it's a good thing, to connect the core tty > devices to their dev_t handler internally, before we init all the > other drivers and run userspace. Um, how early? (/me searches lkml.org for the original patch). Ah, OK, you want to do it postcore.... There may actually be a problem with that, because it looks like vtconsole_class_init (which is currently run as a postcore initcall) really wants to happen before the tty layer initializes itself. So moving tty into postcore could potentially run into problems, depending on whether vt.c's or tty_io.c's initcalls are run first. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html