![]() | ||||||||||
Messages in this thread |
On Monday 14 January 2002 02:09 pm, Alexander Viro wrote: > But it still leaves you with tristate - instead of yes/module/no it's > yes/yes, but don't put it on initramfs/no. However, dependencies become > simpler - all you need is "I want this, that and that on initramfs" and > the rest can be found by depmod (i.e. configurator doesn't have to deal > with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there > (== can't be M)"). This is something I've wondered about and would like to ask for clarification on: the relationship between the initramfs image and the kernel, build process-wise. How much of the build process for the initramfs will be integrated with the kernel build? Since the kernel won't boot without a matching initramfs, I take it that some kind of initramfs will be a kernel build target now? There's been a lot of talk about having the source for a mini-libc (uclibc, dietlibc, some combo) in the kernel tree, and other people saying we should just grab the binary for build purposes. The most obvious model I can think of for klibc staying seperate from the kernel is the user-space pcmcia/cardbus hotplug stuff, but that DID get integrated into the kernel. The klibc source/binary debate still seems to be ongoing, but apart from that, will the build process for initramfs be part of the kernel build or not? Rob. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 12:22 [from the cache] ©2003-2008 | ||||||||||