Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

[Kyle Moffett]

On Fri, May 1, 2009 at 9:12 AM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
>> a) running before /dev/null and /dev/console requires hacks
>
> Not really, well not if you are writing a serious small tool anyway. In
> actual fact the bigger problem if you are using the standard dynamic
> link setup (which you wouldn't be I suspect) is /dev/zero.
>
>> b) it requires an initramfs
>> c) it pulls everything that hooks into or otherwise affects udev into
>> the initramfs; that's much more than we have at present, and a bigger
>> initramfs' can only make bootup _slower_.
>
> Ditto a bigger kernel. Remember moving stuff from initramfs to the kernel
> makes it less memory efficient usually as its now harder to get rid of
> and not pageable later on either.

Hmm... I'm almost curious how early it is possible to start userspace,
if you ensure that the userspace is very careful to limit its
dependencies.  Specifically, you could actually include software
that's little more than a paged kernel thread with its own mm.  If
there's any userspace code that we would really want to be updated in
lockstep with the kernel (possibly this udev-replacement), it could be
originally linked as part of the kernel image and later marked as
swappable pages.

So then the essential questions would be things like:

*  How early can rootfs be set up? (even if not yet populated from the
initramfs)
*  How early can pipefs be ready?
*  What syscalls are safe from that early of a context?

If those questions have satisfactory answers, you could basically
build a mini-udev as a part of the kernel, perhaps even with a
device-table automatically extracted from a specific section by the
linker script.  It would also be useful without an initramfs, as it
could replace the existing root= name-to-dev_t lookup code with
something swappable.

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/