lkml.org 
[lkml]   [2002]   [Jan]   [14]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromRob Landley <>
SubjectRe: Hardwired drivers are going away?
DateMon, 14 Jan 2002 09:19:01 -0500
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