[lkml]   [2009]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs
    Kay Sievers <> writes:

    >> My primary concern is that you are inventing a new mechanism when
    >> the existing mechanism has known issues that could explain the slowdowns.
    > You mean that mounting a new tmpfs at /dev has the issue of being
    > empty?

    I was thinking more along the lines of a single global lock for all of

    > And it takes time to fill it, where you can't reliably do other
    > things at the same time that might need device nodes? Yeah, I guess
    > that's an issue with the existing mechanism, and I'm interested in
    > your proposal to solve it.

    As for that question why not.

    initramfs has always come prepopulated with device nodes.

    It isn't a challenge to mount a new tmpfs somewhere else populate it
    with the basics and them move it onto tmp.

    I would be very surprised if you needed much more than /dev/console,
    /dev/zero and /dev/null for reliable operation of most programs.

    The rest just looks like ensuring you can deal with root (or what
    ever device you care about) showing up after things start running.
    With usb devices apparently not having a guaranteed maximum wait
    and things like dhcp required for network connectivity I don't see
    where adding code to wait for you device to show up would be
    unnecessary logic.

    That said it might make sense to be able to kick off udevd or similar
    before /sbin/init was exec'd. I don't know how much that would gain.

    Numbers like 2 seconds sound absolutely huge in cpu time. And I don't
    have a clue why udev would take anywhere near that long even doing
    everything synchronously. Have you instrumented things up to
    see what takes that much time?


     \ /
      Last update: 2009-05-10 15:44    [W:4.028 / U:8.080 seconds]
    ©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site