Message-ID: <ac3eb2510905021459v41bccb5dy90eba3ed52d9b860@mail.gmail.com>
Date:	Sat, 2 May 2009 23:59:20 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>, Jan Blunck <jblunck@...e.de>,
	linux-arch@...r.kernel.org, viro@...iv.linux.org.uk,
	torvalds@...l.org, akpm@...l.org, adam@...drasil.com
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

On Sat, May 2, 2009 at 23:41, Alan Jenkins
<sourcejedi.lkml@...glemail.com> wrote:
> On 5/2/09, Alan Jenkins <sourcejedi.lkml@...glemail.com> wrote:
>> On 5/2/09, Kay Sievers <kay.sievers@...y.org> wrote:
>>> On Sat, May 2, 2009 at 09:16, Christoph Hellwig <hch@...radead.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.
>>
>> On a narrow issue: do you really object to moving the "mount dev -t
>> devfs2 /dev" into userspace (and therefore giving it a user-visible
>> name)??  That would address Cristophs particular objection about
>> "messing around" with the initial namespace.  It means I can be 100%
>> sure I can boot an old initramfs with this option enabled.  And it
>> gives a nice clean way for new initramfs' to test for this feature -
>> when they try to mount it, it fails.  It would seem to make for a
>> rather smoother migration path.
>>
>> It shouldn't mean too many more LOC, you're already doing the "single
>> instance" thing.
>
> Also, AFAICS this would avoid a memory leak on umount.
>
> In it's original form, if you unmount it, you can't get it back.  But
> it doesn't get destroyed either; all the tmpfs nodes just hang around
> in limbo, right?

Sure you can't get it back if you drop it, but what would be the point
of un-mounting it and wanting it back? It's just like every other
tmpfs too. :)

> It'd be even nicer if it somehow avoided consuming memory when it
> isn't used.

It's probably easy to make it destroy itself, and free everything, if
it's un-mounted, if that solves your concerns about built-in but not
used.

> I guess that requires more code, looks more like a "real"
> devfs, and as C. says is probably more sane if exported as a read
> only.  Hopefully it would make it possible to remove the code
> afterwards, but that sounds like even more work.

Then you should probably not enable it, or have a boot option to
disable it. What's the point in removing it later, it is exactly what
you want, and what everybody has today, a /dev on tmpfs, just that the
kernel will puts the default nodes in there.

> But is read-only so bad?  You just have to copy it over to a tmpfs and
> then mount that on top of /dev.  That's atomic, so it won't interfere
> with parallel early init.  I sympathize, devtmpfs is a really neat
> hack that does exactly what udev needs.  But you have to admit, it
> doesn't fit in _quite_ as well with the kernel status quo.

I think it fits quite nice as a "device node companion" to sysfs. And
I don't really see the point of a read-only mount, it should be the
/dev that is used on the real system, until you shut it down.

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