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]

Date:	Sat, 2 May 2009 23:47:03 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
Cc:	Michael Riepe <michael.riepe@...glemail.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.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 Sat, May 2, 2009 at 21:55, Alan Jenkins
<sourcejedi.lkml@...glemail.com> wrote:
> On 5/2/09, Michael Riepe <michael.riepe@...glemail.com> wrote:

>> Well, what about this? Let the kernel buffer all events until udev is
>> ready to process them. Once it signals that it's up and running - the
>> best method for that is tbd -, empty the queue, and then discard it,
>> including the additional code. If udev doesn't come up in time after
>> init has started, or the buffer overflows, assume the system is using a
>> static /dev and throw away the queue as well. If udev starts too late,
>> it can still do a coldplug - in that case, boot speed is already so low
>> that the additional delay hardly matters.
>
> Already answered by Kay.
> <http://groups.google.com/group/linux.kernel/msg/9851b3f5e82d65ef>
>
> But the premise of this question is bogus anyway.  You don't gain
> anything by capturing events earlier; replaying them is really quite
> cheap, and extracting device numbers and names from sysfs is even
> cheaper.  The gains are in reducing how much processing you need to do
> on them.  Both in terms of performance, and in making it
> simple/neutral enough to be considered for kernel inclusion, which in
> turn brings a number of small benefits.

Exactly, we would add more code, make stuff more complex as it already
is, and gain basically nothing.

It is not about missing events, it is about the bootstrap step we
would like to avoid. Buffering events, or reading all device
information from sysfs at this stage introduces a hard checkpoint,
where we need to bring a process up process these events and create
nodes for them. Only after that we can start other things in userspace
which depend on a working /dev, and with the kernel populated one, we
can just go ahead.

Even when it wouldn't be the fasted we can do, which it probably is,
it would still be the simplest we can do, and that would win in most
cases.

Thanks,
Kay
--
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/