[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac3eb2510905110742h7cd0a546ra922cc2001affd91@mail.gmail.com>
Date: Mon, 11 May 2009 16:42:06 +0200
From: Kay Sievers <kay.sievers@...y.org>
To: Arjan van de Ven <arjan@...radead.org>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
"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 16:30, Arjan van de Ven <arjan@...radead.org> wrote:
>> But he does not use an initramfs, and distros insist to do that. And
>> that basically means you need to prepare /dev two times, and also prep
>
> eh why?
>
> this is the part I'm missing.
> Make /dev in the initramfs, then bind-mount-move it to its final
> location later.
Yeah, sure, that's what distros do, if initramfs was used.
> you ever only need to fill your tmpfs /dev once. initramfs or not.
But you do need to support non-initramfs boot on the same system too,
so you get to provide all that bootstrap logic, mount an empty /dev
and such, ... installed a second time to possibly run from the real
rootfs. That step is partly skipped if initramfs did the tmpfs thing
already, but ...
Initramfs is only used to mount the root and then you leave it behind
you as soon as you can. Only on the real root you find all the
additional udev rules, and tools, which are not available in
initramfs, and you need to re-run the coldplug to apply the
permissions, group ownership, create the configured symlinks, and run
the tools to setup devices.
All these steps involve hard checkpoints where you have to delay other
things that might need device nodes which need to be created first.
Depending on the actual boot setup where you did the bootstrap, the
checkpoint vary.
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/
Powered by blists - more mailing lists