lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 6 Aug 2009 23:18:05 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	Greg KH <greg@...ah.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>,
	Jan Blunck <jblunck@...e.de>, gregkh@...e.de,
	Harald Hoyer <harald@...hat.com>,
	Scott James Remnant <scott@...ntu.com>
Subject: Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

Greg KH wrote:
> On Thu, Aug 06, 2009 at 08:06:16PM +0300, Al Boldi wrote:
> > Andi Kleen wrote:
> > > Greg KH <greg@...ah.com> 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.

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@...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

Powered by Openwall GNU/*/Linux Powered by OpenVZ