linux-kernel - Re: Wait for console to become available, v3.2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090426213746.GH10627@shareable.org>
Date:	Sun, 26 Apr 2009 22:37:46 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	David VomLehn <dvomlehn@...co.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>,
	"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

Alan Stern wrote:
> On Sun, 26 Apr 2009, Jamie Lokier wrote:
> 
> > > Are you suggesting this new interface be exported to userspace somehow?
> > 
> > Not directly.  Only in the same way that open("/dev/console") delays
> > until there's a console, so reading the keyboard can delay until we
> > know if we had a keyboard plugged in at boot, and looking for a disk
> > called UUID=392852908752345749857 can wait until we know if there was
> > one plugged in at boot time.
> > 
> > The latter issue with UUID is done in userspace now by reading all
> > disks, but I'm under the impression changes are planned in that
> > department because reading every disk from userspace to locate
> > specific ones is too slow on big systems.
> 
> IIUC, David is proposing that no userspace process should get started
> until some (all?) of the console devices and the block device
> containing the root filesystem (all block devices present at boot?)
> have been registered.  That would remove the need for your delays, at 
> least in part.
> 
> As for searching for a particular UUID, I believe recent changes to 
> sysfs/udev should improve the situation.  There will be a "by_UUID" 
> directory somewhere, containing a bunch of symbolic links whose names 
> are the UUID values of all the registered drives.  Programs won't have 
> to read every disk; they'll only have to search through this directory.

That will be great.

_If_ the system doesn't wait for all block devices present at boot to
be enumerated before the boot script, then when the script looks in
that directory for a specific UUID, it would be good to wait until 
"has everything present at boot been enumerated?" says yes.

Otherwise you have hacks like my boot script which waits 5 seconds for
a disk to show up on USB, and then continues if not.  It sounds
awfully like waiting X seconds for a USB console to show up :-)

Since this is all about making boot faster, it would be quite nice not
to wait for all block devices before starting the boot script, or at
least the initramfs module-loading script :-)

That's outside the scope of bootconsole and root device.  I certainly
won't demand it's done, but I'm sure you can see a strong similarity:
the ability to wait in the kernel until a class of devices that were
present at boot have finished enumerating.

-- Jamie
--
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/