From: Kay Sievers <kay.sievers@vrfy.org>
To: Christoph Hellwig <hch@infradead.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 13:34:42 +0200 [thread overview]
Message-ID: <ac3eb2510905020434k57b561f7ld3db423f3dba26f0@mail.gmail.com> (raw)
In-Reply-To: <20090502071636.GA9487@infradead.org>
On Sat, May 2, 2009 at 09:16, Christoph Hellwig <hch@infradead.org> wrote:
> >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.
There is nothing like "mess around", it's not mounted at all, until
the kernel mounts the root filesystem at /, then devtmpfs is mounted
the first time, and only if it's compiled in because you asked for it.
Also, just try:
egrep 'mknod|create_dev' init/*.c
and see what we currently do.
> 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.
That sounds worse than devtpfs, and does not help for most of the
mentioned problems we are trying to solve here.
> 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.
And that would solve what? init=/bin/sh would still not work, you can
not bring your box up with that, and you have some pretty useless
unchangeable stuff hanging around in a /dev subdirectory?
>> @@ -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.
There are only a very few places who need this, there nothing ever
like "every driver". It's a very few subsystems, not even the drivers,
if they have more than one. Most device nodes do not have a
subdirectory and don't have that at all.
Thanks,
Kay
next prev parent reply other threads:[~2009-05-02 11:35 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-30 13:23 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
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 [this message]
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=ac3eb2510905020434k57b561f7ld3db423f3dba26f0@mail.gmail.com \
--to=kay.sievers@vrfy.org \
--cc=adam@yggdrasil.com \
--cc=akpm@osdl.org \
--cc=greg@kroah.com \
--cc=hch@infradead.org \
--cc=jblunck@suse.de \
--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
all inboxes | Powered by JetHome®