[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac3eb2510905010411r2c1a2be5s449aaf485a76a8c4@mail.gmail.com>
Date: Fri, 1 May 2009 13:11:36 +0200
From: Kay Sievers <kay.sievers@...y.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Greg KH <greg@...ah.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs
On Fri, May 1, 2009 at 13:03, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> Boot speed, boot speed, boot speed.
>>
>> Oh, and reduction in complexity in init scripts, and saving embedded
>> systems a lot of effort to implement a dynamic /dev properly (have you
>> _seen_ what Android does to keep from having to ship udev? It's
>> horrible...)
>
> This is nothing to do with udev or the kernel side of things. Your
> argument seems to be
>
> "Remove a user space problem and make it a kernel one stuffed in
> unpageable RAM and less flexible"
>
> It seems to me your actual problem is "my tools suck" and the fix for
> that is to fix the tools not add more random kernel junk.
The problem is that people optimize for fractions of seconds today,
driven mainly by your company. :)
No tool ever has a chance to get to the information only available at
early kernel init. All such tools will need to "replay" what the
kernel already did. This is intended to save us from doing this, and
retain the information which is there, but lost at the moment the
tools have the first chance to run.
It's not about a sucking tool, its just impossible. And there is no
space wasted, it's a single string for a very few subsystems, an
nothing is stored per device.
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