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

    > I thought it was a useful comparison.  Start udev early enough, and
    > you could avoid re-doing absolutely anything.  Thinking about, the
    > reasons it doesn't work are
    >
    > a) running before /dev/null and /dev/console requires hacks
    > b) it requires an initramfs
    > c) it pulls everything that hooks into or otherwise affects udev into
    > the initramfs; that's much more than we have at present, and a bigger
    > initramfs' can only make bootup _slower_.

    Exactly. That can not work, we always need to do the coldplug in the
    rootfs, because only there are all the tools we require.

    With the automatic devtmpfs mount in the rootfs, we can do most of the
    coldplug in the background, because other stuff can be sure that
    mandatory device nodes already exist, and they do not need to wait for
    udev to finish.

    Inside the initramfs, the need for coldplug is very much limited to
    module loading and block device handling, and has also no hard
    checkpoint anymore, when devtmpfsl pre-populates /dev.

    Static /dev entries are no option anymore, with all the dynamic number
    assignments today. It might be fine for custom systems, but distros
    can not use it at all. And even for the custom setups, which could do
    it, devtmpfs should be the most flexible and reliable option.

    I think the init=/bin/sh case alone would be worth to do it, without
    any of the other optimizations it makes possible. It's a pretty
    difficult to manage situation today, if your userspace breaks, and you
    need to get to your devices, and /dev is empty, contains entries with
    the wrong numbers, or does not contain what you are looking for.

    Thanks,
    Kay
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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