Re: [Acpi] Re: ACPI fundamental locking problems

[Jeff Garzik <jgarzik@mandrakesoft.com>]

Eugene Crosser wrote:
> 
> In article <Pine.GSO.4.21.0107070727030.24836-100000@weyl.math.psu.edu>,
>         Alexander Viro <viro@math.psu.edu> writes:
> 
> >> Doesn't the approach "treat a chunk of data built into bzImage as
> >> populated ramfs" look cleaner?  No need to fiddle with tar format,
> >> no copying data from place to place.
> >
> > What the hell _is_ "populated ramfs"? The thing doesn't live in array
> > of blocks. Its directory structure consists of a bunch of dentries.
> 
> I am stupid.  But the point still stays: having an image of pre-populated
> filesystem (some other than ramfs) that you only need to load into
> RAM seems more sutable than parsing tar format.  Maybe (probably) I am
> missing something.

Yeah -- we build all this stuff dynamically.  struct file, struct inode,
etc.  You could store them on disk as they would be represented in
memory, but this would be incredibly inefficient because of all the
runtime structures unnecessary on disk, and because of all the fixups
and checks you would have to perform on the data in the images after
they magically appear in memory.

Reading a tarball is the distillation of what you describe into
efficient form :)

-- 
Jeff Garzik      | A recent study has shown that too much soup
Building 1024    | can cause malaise in laboratory mice.
MandrakeSoft     |