lkml.org 
[lkml]   [2006]   [Jun]   [7]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
From"H. Peter Anvin" <>
SubjectRe: klibc (was: 2.6.18 -mm merge plans)
DateTue, 6 Jun 2006 21:10:17 -0700 (PDT)
Followup to:  <200606071400.49980.ncunningham@linuxmail.org>
By author:    Nigel Cunningham <ncunningham@linuxmail.org>
In newsgroup: linux.dev.kernel
> 
> Hi.
> 
> Sorry for coming in late. I've only just resubscribed after my move.
> 
> Not sure who originally said this...
> 
> > > > problems it entails.)  The initial code to have removed
> > > > is the root-mounting code, with all the various ugly
> > > > mutations of that (ramdisk loading, NFS root, initrd...)
> 
> Could I get more explanation of what this means and its implications? I'm 
> thinking in particular about the implications for suspending to disk. Will it 
> imply that everyone will _have_ to have an initramfs with some userspace 
> program that sets up device nodes and so on, even if at the moment all you 
> have is root=/dev/hda1 resume2=swap:/dev/hda2?
> 

Yes.  That initramfs is embedded in the kernel image.

> Along similar lines, I had been considering eventually including support for 
> putting an image in place of the initrd (for embedded).

You can still override the default buildin initramfs.  Then you get
the benefit of not carrying a bunch of code with you that can never be
executed.

	-hpa


-
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: 2006-06-07 06:13    [from the cache]
©2003-2008