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:	Fri, 1 May 2009 13:13:16 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>, Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

On Fri, May 1, 2009 at 12:19, Alan Jenkins
<sourcejedi.lkml@...glemail.com> wrote:
> On 4/30/09, Kay Sievers <kay.sievers@...y.org> wrote:

>> With the kernel populated /dev, existing initramfs or kernel-mount
>> bootup logic can be optimized to be more efficient, and not to require a
>> full coldplug run, which is currently needed to bootstrap the inital
>> /dev directory content, before continuing bringing up the rest of
>> the system. There will be no missed events to replay, because /dev is
>> available before the first kernel device is registered with the core.
>> A coldplug run can take, depending on the speed of the system and the
>> amount of devices which need to be handled, from one to several seconds.
>
> Aren't you overeaching in your claims here?  I'm sure you can't avoid
> at least one coldplug run on a contemporary general purpose system,

You still need coldplug, sure. But distros have 2 full coldplugs
today, one in initramfs, one in the rootfs.

> because you lose so much of the functionality provided by udev.

No, udev will do the same thing as it does today, it will not be
different, it's just that the colplug can run in parallel with other
stuff, and the initramfs coldplug can be much simplified, or even
avoided.

> I'm
> sure of that, but it would be nice if you could address it in the
> changelog.  And modern initramfs' require udev RUN rules to read UUIDs
> and set up LVM.

A simple uuid/label lookup will not need a full coldplug run in
initramfs. You just need to start udev, and wait for the links to show
up. Possibly running triggering block events, but not the hundreds of
other devices.

> I'm loving this for embedded, init=/bin/sh, and rescue floppies :-).
> But I can't understand how you plan to use this as an optimisation.
>
> And - I'm sure you must have considered this in a moment of madness -
> do you know why we couldn't just start _udev_ "before the first kernel
> device is registered with the core"?

I think it's pretty obvious, that this is the fastest you can get for
/dev. And it's not about the time when udev is started, its about
doing the stuff when the devices are created, and not to need to redo
it at bootup, or do it even twice.

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/