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:	Wed, 5 Aug 2009 11:51:36 -0700
From:	Greg KH <greg@...ah.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	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 Wed, Aug 05, 2009 at 11:28:05AM -0700, Greg KH wrote:
> On Wed, Aug 05, 2009 at 07:20:37PM +0100, Alan Cox wrote:
> > On Wed, 5 Aug 2009 10:15:13 -0700
> > Greg KH <greg@...ah.com> wrote:
> > 
> > > Here's the devtmpfs patch again.  For .32 it's a simple and clean patch.
> > 
> > You seem to have reposted it rather than anyone addressing any of the
> > complaints people made about ?
> > 
> > To quote Christoph
> > 
> > > What tree did you find with devtmpfs in it?  It was pretty clearly
> > > rejected when it came up.
> 
> That's not anything to address, what do you want me to say, "maple"?  :)
> 
> > and Arjan (who is doing about the fastest Linux boot anyone has and has
> > better data than anyone else)
> 
> We did this work based on Arjan's work.  It solves a problem that Moblin
> has as well, which is why Novell is using it for their Moblin-based
> images they are shipping.  It makes things go faster, with a simpler
> userspace codepath, and we have the numbers as have been previously
> posted.

And to expound on this a bit, it's not just about fast boot, although
this is a great benefit of this patch.

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.

And then there's the great reason Kay previously stated, "if sysfs has
all the names, numbers, and device properties, why would we need complex
userspace to have the nodes?"

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/