linux-kernel - Re: [PATCH 1/5] KERNEL: Support asynchronously-discovered boot devices, v4 (resend)

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]

Date:	Fri, 1 May 2009 09:58:03 -0700
From:	David VomLehn <dvomlehn@...co.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	linux-scsi@...lxvomd02.corp.sa.net, netdev@...lxvomd02.corp.sa.net
Subject: Re: [PATCH 1/5] KERNEL: Support asynchronously-discovered boot
	devices, v4 (resend)

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@...land.harvard.edu> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/