lkml.org 
[lkml]   [2009]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs
    From
    On 5/2/09, Kay Sievers <kay.sievers@vrfy.org> wrote:
    > On Sat, May 2, 2009 at 22:22, Alan Jenkins
    > <sourcejedi.lkml@googlemail.com> 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
    Alan


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