public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Riepe <michael.riepe@googlemail.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Lars Marowsky-Bree <lmb@suse.de>,
	Alan Jenkins <sourcejedi.lkml@googlemail.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>, Greg KH <greg@kroah.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jan Blunck <jblunck@suse.de>
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs
Date: Mon, 04 May 2009 19:54:28 +0200	[thread overview]
Message-ID: <49FF2BD4.3070409@googlemail.com> (raw)
In-Reply-To: <ac3eb2510905040953t29e104eel1f820516195c623a@mail.gmail.com>

Hi!

Kay Sievers wrote:

> 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 what about mounting /dev from an already populated image? Or, even
faster, using the /dev directory of the root fs? That way, the device
nodes would be present as soon as / is mounted, without any additional
overhead, except the very first time the system boots (in case you
choose not to populate /dev with a default set of device nodes in advance).

I know, not using tmpfs is a security risk and whatever. But does that
really matter in an embedded system where you have no user accounts?

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

You can do that with a persistent /dev as well. It will even keep the
symlinks udev created before the system rebooted. The only drawback is
that you have to wait for device nodes that belong to new devices which
were connected to the system while it was down. But that rarely happens,
and will eventually be fixed by udev.

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

Pardon me, but I have to ask this: Isn't your patch a custom hack, too?

-- 
Michael "Tired" Riepe <michael.riepe@googlemail.com>
X-Tired: Each morning I get up I die a little

  reply	other threads:[~2009-05-04 17:54 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-30 13:23 [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs Kay Sievers
2009-05-01  5:29 ` Andrew Morton
2009-05-01  6:17   ` Greg KH
2009-05-01  6:43     ` Andrew Morton
2009-05-01  6:55       ` Greg KH
2009-05-01  7:03         ` Andrew Morton
2009-05-01 10:52           ` Kay Sievers
2009-05-01 11:38             ` Michael Tokarev
2009-05-01 11:44               ` Kay Sievers
2009-05-01 11:03         ` Alan Cox
2009-05-01 11:11           ` Kay Sievers
2009-05-01 13:18             ` Alan Cox
2009-05-01 13:24               ` Kay Sievers
2009-05-02  7:19                 ` Christoph Hellwig
2009-05-02 13:46                   ` Kay Sievers
2009-05-02 15:18                     ` Andy Lutomirski
2009-05-02 15:35                       ` Kay Sievers
2009-05-02 18:20                 ` Michael Riepe
2009-05-02 19:55                   ` Alan Jenkins
2009-05-02 21:47                     ` Kay Sievers
2009-05-04 16:20                       ` Lars Marowsky-Bree
2009-05-04 16:53                         ` Kay Sievers
2009-05-04 17:54                           ` Michael Riepe [this message]
2009-05-04 18:13                             ` Kay Sievers
2009-05-04 18:55                               ` Michael Riepe
2009-05-04 19:13                                 ` Kay Sievers
2009-05-04 19:30                                 ` Greg KH
2009-05-02  1:24         ` Brian Swetland
2009-05-02  1:48           ` Kay Sievers
2009-05-02  2:02             ` Brian Swetland
2009-05-02  2:28               ` Kay Sievers
2009-05-02  4:42                 ` Brian Swetland
2009-05-02 13:30                   ` Kay Sievers
2009-05-01 11:01     ` Alan Cox
2009-05-01 11:02       ` Kay Sievers
2009-05-01 11:16   ` Kay Sievers
2009-05-01 19:26     ` Andrew Morton
2009-05-01 21:59       ` Kay Sievers
2009-05-01 22:21         ` Andrew Morton
2009-05-01  6:57 ` Chris Wedgwood
2009-05-01 14:01   ` Greg KH
2009-05-01 15:43     ` Alan Jenkins
2009-05-01 16:04       ` Greg KH
2009-05-01 21:13         ` Alan Jenkins
2009-05-01 15:53     ` Chris Wedgwood
2009-05-01 16:09       ` Greg KH
2009-05-01 16:17         ` Chris Wedgwood
2009-05-01 10:19 ` Alan Jenkins
2009-05-01 11:13   ` Kay Sievers
2009-05-01 12:38     ` Alan Jenkins
2009-05-01 13:12       ` Alan Cox
2009-05-02 15:03         ` Kyle Moffett
2009-05-01 14:55       ` Kay Sievers
2009-05-01 11:41 ` Hugh Dickins
2009-05-01 11:59   ` Kay Sievers
2009-05-02  7:16 ` Christoph Hellwig
2009-05-02 11:34   ` Kay Sievers
2009-05-02 20:22     ` Alan Jenkins
2009-05-02 21:39       ` Kay Sievers
2009-05-02 22:04         ` Alan Jenkins
2009-05-03  7:29           ` Michael Tokarev
2009-05-02 21:41       ` Alan Jenkins
2009-05-02 21:54         ` Greg KH
2009-05-02 21:59         ` Kay Sievers
2009-05-02 16:59   ` Jeff Garzik
2009-05-02 17:57     ` Kay Sievers
2009-05-06 12:56 ` Kay Sievers
2009-05-07  1:41 ` Arjan van de Ven
2009-05-07  2:08   ` Kay Sievers
2009-05-07  2:25     ` Arjan van de Ven
2009-05-07  2:40       ` Kay Sievers
2009-05-14  9:28     ` Pavel Machek
2009-05-07  8:17 ` Eric W. Biederman
2009-05-07  9:28   ` Kay Sievers
2009-05-07 14:43     ` Theodore Tso
2009-05-07 15:13       ` Kay Sievers
2009-05-10  0:29     ` Eric W. Biederman
2009-05-10  0:56       ` Kay Sievers
2009-05-10  2:11         ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49FF2BD4.3070409@googlemail.com \
    --to=michael.riepe@googlemail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=jblunck@suse.de \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lmb@suse.de \
    --cc=sourcejedi.lkml@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox