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: <Pine.LNX.4.44L0.0904261715250.26439-100000@netrider.rowland.org>
Date:	Sun, 26 Apr 2009 17:20:54 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jamie Lokier <jamie@...reable.org>
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

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.

Alan Stern

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ