From: Kay Sievers <kay.sievers@vrfy.org>
To: Jamie Lokier <jamie@shareable.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
David VomLehn <dvomlehn@cisco.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>, Ingo Molnar <mingo@elte.hu>,
Arjan van de Ven <arjan@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux USB Mailing List <linux-usb@vger.kernel.org>,
Linux Embedded Mailing List <linux-embedded@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Wait for console to become available, v3.2
Date: Mon, 27 Apr 2009 00:36:48 +0200 [thread overview]
Message-ID: <ac3eb2510904261536t7a37f970tfafba71d1e67cfb6@mail.gmail.com> (raw)
In-Reply-To: <20090426213746.GH10627@shareable.org>
On Sun, Apr 26, 2009 at 23:37, Jamie Lokier <jamie@shareable.org> wrote:
> Alan Stern wrote:
>> 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.
It is like that for years now, and it is completely in userspace at
/dev/disk/by-uuid/. I don't know of any plans to add filesystem/raid
signature uuid probing support to the kernel. And I think that will be
almost impossible to get right in the kernel.
Yes, you need to look at all the disks from userspace, if you request
to mount them by filesystem metadata like label/UUID. It works fine
even on boxes with thousands of disks.
> _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.
That's what distros do with initramfs today.
> 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 :-)
You wait in initramfs until the device show up. Usually dynamic udev
rules created from the root= string of the kernel commandline create a
rule which matches on the UUID, and creates a /dev/root symlink when
the device shows up. As soon as this link shows up, init mounts it
and goes ahead.
Thanks,
Kay
next prev parent reply other threads:[~2009-04-26 22:36 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-20 23:40 Wait for console to become available, v3.2 David VomLehn
2009-04-21 6:43 ` Ingo Molnar
[not found] ` <20090421064346.GB8020-X9Un+BFzKDI@public.gmane.org>
2009-04-21 7:13 ` David Brownell
2009-04-21 8:03 ` Ingo Molnar
2009-04-21 17:11 ` David Woodhouse
2009-04-21 17:29 ` David VomLehn
[not found] ` <20090421172929.GC8251-CFZJ1or75eBPWxJt6d6B6bQa8qPdvLwY@public.gmane.org>
2009-04-21 17:37 ` Linus Torvalds
2009-04-21 17:59 ` David VomLehn
2009-04-21 17:41 ` David Woodhouse
2009-04-21 17:31 ` Linus Torvalds
[not found] ` <alpine.LFD.2.00.0904211016190.2199-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-04-21 19:25 ` Alan Cox
2009-04-21 23:17 ` David VomLehn
2009-04-22 8:25 ` Jamie Lokier
2009-04-22 9:11 ` Alan Cox
[not found] ` <20090422101109.7beee3ee-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
2009-04-22 10:39 ` Jamie Lokier
2009-04-21 13:35 ` Arjan van de Ven
[not found] ` <20090421063549.3b71881d-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2009-04-21 13:50 ` Ingo Molnar
[not found] ` <20090421135034.GA30114-X9Un+BFzKDI@public.gmane.org>
2009-04-21 14:05 ` Jamie Lokier
2009-04-21 14:26 ` Ingo Molnar
[not found] ` <20090421142627.GA18129-X9Un+BFzKDI@public.gmane.org>
2009-04-21 14:37 ` Alan Cox
2009-04-22 8:22 ` Jamie Lokier
2009-04-22 9:13 ` Alan Cox
2009-04-21 16:42 ` David VomLehn
2009-04-21 14:36 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.0904211026080.2981-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2009-04-21 16:52 ` David VomLehn
2009-04-21 19:09 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.0904211457150.3986-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2009-04-21 23:08 ` David VomLehn
2009-04-22 15:40 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.0904221111320.3405-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2009-04-22 20:54 ` David VomLehn
2009-04-22 21:08 ` Alan Cox
2009-04-22 21:24 ` Alan Stern
2009-04-24 0:35 ` David VomLehn
[not found] ` <20090424003555.GA31173-CFZJ1or75eBPWxJt6d6B6bQa8qPdvLwY@public.gmane.org>
2009-04-24 19:20 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.0904241502440.4531-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2009-04-24 21:32 ` David VomLehn
2009-04-24 22:19 ` Jamie Lokier
[not found] ` <20090424221951.GC18260-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2009-04-24 23:10 ` David VomLehn
[not found] ` <20090424231013.GA18340-CFZJ1or75eBPWxJt6d6B6bQa8qPdvLwY@public.gmane.org>
2009-04-25 1:41 ` Jamie Lokier
2009-04-25 3:11 ` Alan Stern
2009-04-26 19:52 ` Jamie Lokier
2009-04-26 21:20 ` Alan Stern
2009-04-26 21:37 ` Jamie Lokier
2009-04-26 22:36 ` Kay Sievers [this message]
2009-04-26 23:12 ` Jamie Lokier
2009-04-26 23:23 ` Kay Sievers
2009-04-26 23:46 ` Jamie Lokier
[not found] ` <20090425014152.GD23106-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2009-04-26 17:55 ` David VomLehn
2009-04-22 5:35 ` David VomLehn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ac3eb2510904261536t7a37f970tfafba71d1e67cfb6@mail.gmail.com \
--to=kay.sievers@vrfy.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=dvomlehn@cisco.com \
--cc=hpa@zytor.com \
--cc=jamie@shareable.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).