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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090430145412.c1386cb2.akpm@linux-foundation.org>
Date:	Thu, 30 Apr 2009 14:54:12 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	dvomlehn@...co.com, 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, 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?

y:/usr/src/linux-2.6.30-rc4> grep -ril initdev . 
./drivers/scsi/mpt2sas/mpi/mpi2_ioc.h
./drivers/net/mac8390.c
./drivers/video/kyro/Makefile
./drivers/video/kyro/STG4000InitDevice.c
./drivers/message/fusion/lsi/mpi_ioc.h
./drivers/watchdog/i6300esb.c
./drivers/media/video/cx88/cx88-alsa.c
./drivers/media/video/cx88/cx88-video.c
./drivers/media/video/saa7134/saa7134-core.c
./drivers/media/video/cx23885/cx23885-core.c

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.

> 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?
--
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/