Message-ID: <ac3eb2510905040953t29e104eel1f820516195c623a@mail.gmail.com>
Date:	Mon, 4 May 2009 18:53:40 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Lars Marowsky-Bree <lmb@...e.de>
Cc:	Alan Jenkins <sourcejedi.lkml@...glemail.com>,
	Michael Riepe <michael.riepe@...glemail.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

On Mon, May 4, 2009 at 18:20, Lars Marowsky-Bree <lmb@...e.de> wrote:
> On 2009-05-02T23:47:03, Kay Sievers <kay.sievers@...y.org> wrote:
>
>> It is not about missing events, it is about the bootstrap step we
>> would like to avoid. Buffering events, or reading all device
>> information from sysfs at this stage introduces a hard checkpoint,
>> where we need to bring a process up process these events and create
>> nodes for them. Only after that we can start other things in userspace
>> which depend on a working /dev, and with the kernel populated one, we
>> can just go ahead.
>
> So if udevd was present before the kernel started scanning devices this
> would not be as much of a problem, would it?

It is too early, you would need a working userspace environment to
start a process like udev, which we don't have at this point. You
really want to catch the creation of /dev/null and /dev/console and
such, and there is no real chance to run anything like udev reliably
at this stage.

> (Couldn't udevd trigger the device scan? Could it be started so early as
> for this not to matter?)

The driver-core is basically "80% of basic udev" in the kernel - the
/dev part is just the last missing piece. :)

The problem is not the missing events, they could be pretty easily
recovered from sysfs with just another special hack to run at bootup -
it's the time it takes to bring up the engine to bootstrap /dev, to
allow us to start any other process which looks for devices. Today,
udev mounts /dev as a tmpfs, and at that point it is obviously empty,
and needs to be filled, and nothing else can reliably run at that
time.

> And isn't part of the problem that you have a choke point in the
> dependency graph - namely "/dev working" as a predicate for running
> certain services/scripts - instead of more fine-grained dependencies for
> just the devices they need?

Without the basic devices, you can not start anything "normal", and
currently it's udev which provides /dev/null /dev/console,
/dev/random, the ttys, or whatever which might be needed you can not
know in advance.
  The plan is to start udevd, but run the coldplug in the background
and start other stuff in parallel, because you can be sure that all
currently known devices are already there, and the missing meaningful
symlinks created by udev will show up soon, along with a new event to
hook into. There will be no hard checkpoint anymore to wait for the
basic environment..

The other important reason besides that it saves us from coming up
with just another custom hack to fill the initial /dev, is that it is
damn simple and very reliable. It allows init=/bin/sh to just work,
and /dev has the same logic when an initramfs is used, or the kernel
mounts the rootfs. And simpler is almost always better - and I think
it's also the fastest we can do.

Thanks,
Kay
--
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