[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0905011308460.2989-100000@iolanthe.rowland.org>
Date: Fri, 1 May 2009 13:20:00 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: David VomLehn <dvomlehn@...co.com>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Kernel development list <linux-kernel@...r.kernel.org>,
USB list <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 1/5] KERNEL: Support asynchronously-discovered boot
devices, v4 (resend)
On Fri, 1 May 2009, David VomLehn wrote:
> > OK, so "initdev" could be viewed as meaning "a device which /sbin/init
> > needs"? Even I can understand that.
> >
> > But /sbin/init isn't the first userspace we run, is it? There's
> > initramfs stuff, firmware loaders, etc.
> >
> > What's the story here? Do we intend that all initdevs be up and
> > running before _any_ userspace runs? Or is /sbin/init the red line?
>
> I've avoided making any guarantees about this, but /sbin/init is implicitly
> the red line. If we make this explicit, we're probably back in the vicinity
> of the bike shed, but this should help frame any subsequent discussion
> in a concrete manner.
This matter is a little unclear, to me at least. Consoles, yes, I
think we do want the console to be connected when the first user
process -- whether it is an initramfs or /bin/init or whatever --
starts up (if a console device does exist).
But the root filesystem is another story. The initramfs or initrd may
itself load the necessary drivers. Waiting for the root device to show
up then is no longer the kernel's responsibility. However if there is
no initramfs then the kernel should indeed wait for the root device to
exist before trying to mount the root filesystem and start /bin/init.
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