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:	Thu, 6 Aug 2009 21:25:44 -0700
From:	Greg KH <greg@...ah.com>
To:	Al Boldi <a1426z@...ab.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

On Fri, Aug 07, 2009 at 07:03:40AM +0300, Al Boldi wrote:
> Greg KH wrote:
> > On Thu, Aug 06, 2009 at 11:18:05PM +0300, Al Boldi wrote:
> > > So really, if devtmpfs compares to udev speeds then this just looks like
> > > a devfs comeback.  Remember, devfs was really slow.
> >
> > Again, there is no "speed" for devtmpfs on its own, the device nodes
> > just appear when the devices are added to the kernel, the speed of that
> > depends on the device discovery within the kernel, nothing else.
> 
> So on bootup this would mean a lot of discovery.

Yes, all of this happens within the kernel, like normal.  What are you
getting at?

> I think we could get some big speedup, by just dumping the possible 
> non-realized device list on bootup, and then just refine it on physical 
> access.  This could make devtmpfs an acceptable replacement to static /dev.

Um, that's exactly what devtmpfs does, it creates the nodes based on
the fact that the devices were physically (or virtually for some
devices) discovered and registered with the kernel.  This happens at the
same time the existing uevents are generated and sent out to userspace.

I think you are getting very confused here as to what is going on,
perhaps you should read the code a bit more to understand it better.

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/