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: <ac3eb2510905020646k28ebaf07j2216c6f3f614748c@mail.gmail.com>
Date:	Sat, 2 May 2009 15:46:03 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	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 09:19, Christoph Hellwig <hch@...radead.org> wrote:
> On Fri, May 01, 2009 at 03:24:01PM +0200, Kay Sievers wrote:
>> I'm very sure, you can not fix it outside the kernel. Or do you have
>> an idea how to create the missing device nodes for device without
>> crawling sysfs, when the first userspace process is started?
>
> Just make sure to queue up your uevents in a ring buffer that udev
> can read once it has started?

Which does not really target any of the problems we try to solve, and
is probably even larger than the 300 lines to create the proper /dev
stuff right away. It's about fractions of a second, we are optimizing
for, and we need to start as many things in parallel, as early as
possible. And a working and populated /dev is mandatory for most of
the stuff we need to bring up.

I think the init=/bin/sh case alone would be justification enough to
do that, it can save you a lot of trouble if things go wrong, which
things do, and which is pretty hard to cope with today, with no access
to your devices.

We are not implementing anything crazy here like devfs did, including
the later versions - there is no modprobe behind your back, no lookup
hooks, no stupid new naming scheme, no new filesystem type to
register.
Udev uses the kernel provided names anyway today, there are no naming
rules at all in current userspace for 98 of 100 devices. It's todays
kernel which provides the naming already, and we will not change
anything here, just add the few exceptions, which are only in udev
rules today, and let the kernel create the node that udev will create
anyway.

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/