linux-kernel - Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 7 Aug 2009 15:24:49 -0700
From:	Greg KH <greg@...ah.com>
To:	Al Boldi <a1426z@...ab.com>
Cc:	Chris Friesen <cfriesen@...tel.com>,
	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

On Sat, Aug 08, 2009 at 12:17:31AM +0300, Al Boldi wrote:
> Chris Friesen wrote:
> > Greg KH wrote:
> > > On Fri, Aug 07, 2009 at 08:04:08AM +0300, Al Boldi wrote:
> > >> The question is, how fast can devtmpfs get the device list from the
> > >> kernel on bootup?  How much faster than udev?  How much slower than
> > >> static /dev?
> > >
> > > It's much faster than udev, and is equivalent to a static /dev with the
> > > exception that the group and permission settings that you are used to.
> > > udev then needs to come along and make those settings, but that's so
> > > frickin fast it's amazing.
> >
> > Earlier in the thread you indicated a 0.5sec speedup over udev.  Is that
> > really considered "much faster"?
> >
> > I do agree that it makes sense to do this, but more from an elegance
> > view than a performance one.
> 
> It's definitely more elegant, but at what cost?

You've seen the patch, you tell me :)

> For devtmpfs to be a realistic replacement for static /dev, it has to
> be comparable to static /dev in both speed and size.

Since when is this requirement necessary?  You want something for free
in both speed and size?  Well, you got it in speed, but not size, it
will take up memory that is swapable, and a tiny ammount of non-swapable
kernel memory for the code.

> WRT speed, there should be no  slowdown and it should be just as fast
> as a "tar -xp < dev.tar".

Again, where is this requirement coming from?

Have you timed devtmpfs?  Have you timed your tar extraction?  What is
the difference, and since when does anyone use tar of a static dev tree
at boot time?

> WRT size, it should not be dependent on hotplug, and instead offer
> hotplug as an option.

Um, again, who made up such a requirement?  Are you running systems
today with CONFIG_HOTPLUG disabled?  If so, how well is that working for
you?

thanks,

greg k-h
--
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/