[lkml]   [2009]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs
On 5/2/09, Kay Sievers <> wrote:
> On Sat, May 2, 2009 at 22:22, Alan Jenkins
> <> wrote:
>> 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.
> An argument which does not stand at all, there is no mess, it is not
> mounted at all until we are ready with initializing the kernel. And
> instead of creating some random nodes in /dev like we do today, we
> mount it, and it contains a node for every device. I hardly see any of
> the mentioned "namespace mess" here, it's just the simplest, most
> robust, and most efficient thing we can do. :)
>> It means I can be 100%
>> sure I can boot an old initramfs with this option enabled.
> Oh, it does not change anything for an existing initramfs, if that
> option enabled. After initramfs found and mounted the real rootfs at
> /root, your are totally free to call:
> mount --move /dev/ /root/dev
> or not to do that, like we do today.

Sorry, you're right. I should go to bed :-).

It would matter if you had a different naming scheme for /dev than the
kernel, and you were trying to get away with a static /dev. I can't
believe anyone important does that though :-).

>> 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.
> I think that is all covered just fine.

Oh, I see.

grep "/dev" /proc/mounts > /dev/null

> One thing that I tried to solve by doing a kernel mounted fs, is that
> /dev on the rootfs is completely empty, it is that way on some distros
> today, and if you do init=/bin/sh, it will not work, because
> /dev/console is missing.
> Another thing, why I would like to avoid a new fstype is that
> userspace checks if /dev is a tmpfs to find out if it's a dynamic /dev
> - nothing really that should prevent us from doing a new filesystem,
> but we should need a good reason to do it, I think.

I thought udev was documented somewhere as compatible with a non-tmpfs
/dev, in a "just because you could" sort of way. I've seen something
test for tmpfs... nevermind, it's probably something different. (Just
the init script that checks whether /dev has been mounted that way by
an initramfs, or the user decided to do without intramfs' so the
rootfs gets to mount it instead).

Good night

 \ /
  Last update: 2009-05-03 00:07    [W:0.126 / U:0.048 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site