linux-kernel - Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

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]

Message-ID: <20090501160951.GA17433@kroah.com>
Date:	Fri, 1 May 2009 09:09:51 -0700
From:	Greg KH <greg@...ah.com>
To:	Chris Wedgwood <cw@...f.org>
Cc:	Kay Sievers <kay.sievers@...y.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev
	tmpfs

On Fri, May 01, 2009 at 08:53:42AM -0700, Chris Wedgwood wrote:
> On Fri, May 01, 2009 at 07:01:08AM -0700, Greg KH wrote:
> 
> > Right now it does, and it takes about 1-2 seconds to do so depending
> > on the hardware.
> 
> The code I have only does block devices right now, but it could do
> more.  Even if it was 10x slower it wouldn't be close to 1-2 seconds.

You usually need to do more.  We started out just only doing block
devices, but you also need the memory devices, and console, and a few
others as well.

After all that, you have already written another tool, which seems like
overkill when we can do it all in the kernel so much easier and simpler.

> > Which is over double the time it takes to boot the kernel entirely
> > these days, so it is quite noticable.
> 
> So the kernel takes 500-1000ms then?  That seems really high.

Yes, we can boot a kernel in 500-1000ms on some pretty low end, crappy
disk controller/device laptops these days.  Yes, it's not as fast as we
would like it, but we are working on making it even faster.  I think
Arjan has some pending patches to resolve some of the remaining issues
that are present for machines with "legacy" input devices that we need
to get merged.

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/