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

Powered by Openwall GNU/*/Linux Powered by OpenVZ