linux-kernel - Re: [patch 00/13] devtmpfs patches

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 May 2009 20:04:16 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Greg KH <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Fabio Comolli <fabio.comolli@...il.com>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: [patch 00/13] devtmpfs patches

On Mon, May 11, 2009 at 19:55, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> The same applies when you leave initiramfs, the in-initramfs udevd
>> copy is killed, and the one from the real root is started. You may
>> miss events in-between, and need to run a full coldplug again, not
>> only to apply the policy, but also to make sure that all nodes are
>> there. The policy can run in the background for most things just fine,
>> the missing node may cause trouble.
>
> What a strange behaviour. Why not run a single udev instance inside the
> tmpfs you are turning into dev and will then attach to the real rootfs
> when it appears ? You only need to build /dev once.

Because the udev in initramfs has no clue about uid/gid, has not the
tools it needs for a full setup, has not the same rules as the one in
the real root. Ignoring the fact, that people may run different
versions in initramfs and the real root. There is no sane option so
far, not to replace the udevd process from initramfs.

>> Yeah, and I mentioned many other ways this is useful, to do stuff in
>> parallel, to be able to rescue, and to have custom systems which do
>
> But there are lots where it is not - and those you've mentioned where it
> might be seem rather stretched at best.

Right, but the information you need for all other use cases is already
there today in /sys. This is about something new, so there is not a
competition about features, just an option to solve a problem in a
different way, which we prefer over the current one.

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/