public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Greg KH <greg@kroah.com>, Jan Blunck <jblunck@suse.de>,
	linux-arch@vger.kernel.org, viro@zeniv.linux.org.uk,
	torvalds@osdl.org, akpm@osdl.org, adam@yggdrasil.com
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs
Date: Sat, 2 May 2009 03:16:36 -0400	[thread overview]
Message-ID: <20090502071636.GA9487@infradead.org> (raw)
In-Reply-To: <1241097822.2516.3.camel@poy>

On Thu, Apr 30, 2009 at 03:23:42PM +0200, Kay Sievers wrote:
> From: Kay Sievers <kay.sievers@vrfy.org>
> Subject: driver-core: devtmpfs - driver core maintained /dev tmpfs

Umm, guys this needs much broader discussion than just sneaking in
a patch under the covers.

It basically does re-introduce devfs under a different name, and from
looking at the implementation it might not be quite as bad a Gooch's
original, but it's certainly worse than Adam Richters rewrite the we
never ended up merging.

Now we might want to revisit the decision to leave all the device name
handling to a userspace daemon, because it provded to be quite fragile
under certain circumstances, and you apparently see performance issues.

> Devtmpfs lets the kernel create a tmpfs very early at kernel
> initialization, before any driver core device is registered. Every
> device with a major/minor will have a device node created in this
> tmpfs instance. After the rootfs is mounted by the kernel, the
> populated tmpfs is mounted at /dev. In initramfs, it can be moved
> to the manually mounted root filesystem before /sbin/init is
> executed.

That for example is something that is not acceptable.  We really don't
want the kernel to mess with the initial namespace in such a major way.

> The tmpfs instance can be changed and altered by userspace at any time,
> and in any way needed - just like today's udev-mounted tmpfs. Unmodified
> udev versions will run just fine on top of it, and will recognize an
> already existing kernel-created device node and use it.
> The default node permissions are root:root 0600. Only if none of these
> values have been changed by userspace, the driver core will remove the
> device node when the device goes away. If the device node was altered
> by udev, by applying the appropriate permissions and ownership, it will
> need to be removed by udev - just as it usually works today.

That's some really, really odd lifetime rules.


Counter-proposal:  Re-introduce a proper mini-devfs.  All nodes in there
are kernel-created and not changeable which sorts out that whole
mess of both drivers and userspace messing with tree topology we had
both in original devfs and this new devtmpfs.  Single-instance so it can be
populated before it's actually mounted somewhere, that way the kernel
doesn't have to do any policy devicision on where it's mounted.  Mount
point would usually be /dev/something so /dev can remaining udev-managed
tmpfs or even manually maintained and symlinks can point into
/dev/something.

> +static char *bsg_nodename(struct device *dev)
> +{
> +	return kasprintf(GFP_KERNEL, "bsg/%s", dev_name(dev));
> +}
> +
>  static int __init bsg_init(void)
>  {
>  	int ret, i;
> @@ -1082,6 +1087,7 @@ static int __init bsg_init(void)
>  		ret = PTR_ERR(bsg_class);
>  		goto destroy_kmemcache;
>  	}
> +	bsg_class->nodename = bsg_nodename;

And adding this gunk to every driver is really ugly.  Must say
late-devfs version of the same defintively was more pretty.

       reply	other threads:[~2009-05-02  7:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1241097822.2516.3.camel@poy>
2009-05-02  7:16 ` Christoph Hellwig [this message]
2009-05-02 11:34   ` [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs 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

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=20090502071636.GA9487@infradead.org \
    --to=hch@infradead.org \
    --cc=adam@yggdrasil.com \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=jblunck@suse.de \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=viro@zeniv.linux.org.uk \
    /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