Re: [PATCH 1/5] KERNEL: Support asynchronously-discovered bootdevices, v4 (resend)

[David VomLehn]

On Thu, Apr 30, 2009 at 02:54:12PM -0700, Andrew Morton wrote:
> On Thu, 30 Apr 2009 17:19:34 -0400 (EDT)
> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> 
> > > I wonder if we can think of something more new ad unique.  startupdev?  yuk.
> > 
> > Initdev?  Or does that mean something else also?
...
> initdev sounds good to me.  Given that we're adding a new and distinct
> concept which will remain with us for a long time, we should name it
> with care.

Yes, we do need a good name, so we are now guaranteed to be entering
the Bike Shed Zone. Personally, I'm fine with initdev and will assume this
is the name going forward. I'll tweak the patches appropriately.

> > Really, these are devices that we want to have working before starting
> > up any userspace processes.  These would be the console device(s) (so
> > that the first process has open files for its stdin, stdout, and
> > stderr) and the block device containing the root filesystem (if the
> > initramfs image doesn't make its own arrangements).
> 
> 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.

David VomLehn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/