[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090421153745.2d8964c7@lxorguk.ukuu.org.uk>
Date: Tue, 21 Apr 2009 15:37:45 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Ingo Molnar <mingo@...e.hu>
Cc: Jamie Lokier <jamie@...reable.org>,
Arjan van de Ven <arjan@...radead.org>,
David VomLehn <dvomlehn@...co.com>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux USB Mailing List <linux-usb@...r.kernel.org>,
Linux Embedded Mailing List <linux-embedded@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Wait for console to become available, v3.2
> +config PRINTK_CONSOLE_WAIT
> + int "Default number of milliseconds to wait for console device"
> + default 1000
>
> Does this only delay init during a console-less bootup - or are
> there other later apps that might trigger the delay?
The console proper needs to be event based not timeout hacks. Can we
please fix this stuff properly ? To start with there is no reason that the
USB console can't implement a "maybe we have hardware, maybe I buffer 64K
until it shows up" behaviour and bind to hardware as and when USB serial
devices get inserted. We do much of this for the VT drivers so we save
messages before PCI and fb come up.
The timeout wait proposed is also wrong I agree. Take a timestamp at the
point we are ready to mount the root fs, any delays on root mount, console
appearance etc should then be tested against this timestamp not as delays
versus some undefined later event.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists