Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based/dev
From: Harald Hoyer
Date: Mon Aug 10 2009 - 05:23:30 EST
On 08/06/2009 10:18 PM, Al Boldi wrote:
Greg KH wrote:
On Thu, Aug 06, 2009 at 08:06:16PM +0300, Al Boldi wrote:
Andi Kleen wrote:
Greg KH<greg@xxxxxxxxx> writes:
It makes the userspace boot process much simpler and easier to
maintain, as well as providing a way to handle rescue disks and
images trivially, and it makes the kernel _less_ dependant on the
early userspace bootup scripts.
As a initrd less kernel user I can really only agree: getting rid
of the udev-in-initrd requirement would be a big step forward
in usability. Typically I always have to pre populate
a on disk /dev manually first to get my kernels to boot.
Oh good, I thought I was the only one doing that.
The reason I don't like udev is that it's just to slow; something like a
5-10s delay on each boot. No idea why it should be so slow, but it's
probably probing the kernel for all available devices at boot, when it
could be much quicker by probing for the device on access.
Like Kay stated, this sounds like a misconfiguration of your distro's
udev setup, as the ones I use (openSUSE and Gentoo) do not have this
problem at all.
Maybe they are using the same trick as Ubuntu and Debian, as they run udev in
the background to hide the slowness. Both Fedora and Mandriva run udev in
the foreground where the slowness is visible.
On Fedora parallel to udev, readahead is running, which makes you think udev is
slow, but in the end readahead speeds up the boot process by 10%.
So really, if devtmpfs compares to udev speeds then this just looks like a
devfs comeback. Remember, devfs was really slow.
Thanks!
--
Al
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/