[lkml]   [1999]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: initrd redesign (was Re: Partition nightmare Was: Migrating to
Werner Almesberger wrote:
> H. Peter Anvin wrote:
> > That would be nice, but may complicate things unneccesarily. In the
> > general case, you may have to worry about garbage-collecting parts of
> > the filesystem that are now unreachable, and that would be majorly
> > painful.
> My assumption is that all file systems are reachable somehow, e.g. via
> some device file. Since you should know fairly well what mess your initrd
> may have left behind, the cleanup should actually be quite simple. Even
> a "general" cleanup mechanism doesn't look too difficult to me, provided
> that you have the access information somewhere (/proc/mount-devs ?).

That seems a little hacky to me...

> > I actually think that an nfsroot.gz initrd would do everything the
> > current kernel mechanism does.
> Yes, and it could even do more clever things than NFS root does right
> now. What I meant was that it's trivial to just make a kernel boot
> floppy, but constructing something with kernel, nfsroot, and boot loader
> is more complex. Naturally, with time, packages and scripts should show
> up to simplify this too.


> > exec() init works just fine. I have used it. I don't think there is
> > any need to put that in kernel space.
> Great, so we're already half there :)


"The user's computer downloads the ActiveX code and simulates a 'Blue
Screen' crash, a generally benign event most users are familiar with
and that would not necessarily arouse suspicions."
-- Security exploit description on

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.052 / U:47.040 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site