equivalent copy-nand interface ideas for XO-1.5

[Paul Fox]

daniel --

excellent trick with the --sparse option to tar.  very neat.

i won't quote anything you wrote, because i have nothing to
add to your lists of pros and cons of those methods.

another possibility:  size the original fs image to the size of
the data it will hold:  i.e., create a filesystem with no free
space.  this will eliminate the sparseness issue when
distributing.  use OFW to write this in a raw, filesystem-unaware
manner.  mark the file system in such a way that the initrd will
know (or perhaps it will simply guess, based on sizing) to resize
the filesystem before mounting, in order that it fill the
available space.  my impression is that the extN filesystems are
fairly easy to grow in place?

another alternative (i'm brainstorming here, be kind :-) is for
the fs to be shipped as part of a special initrd attached to a
kernel which OFW would boot in order to do the installation.  that
feels like a bit of an upheaval to our current schemes, but it
would give a lot of flexibility, in that the payload of that special
initrd could be as dense as we liked, and the installation kernel
could do all manner of system preparation before writing the fs.
(it also assumes that the compressed fs data + kernel will fit in
memory, which on XO-1.5 will hopefully be the case for some time.)

the issues of privacy/security remain with these schemes. 
clearly it would be preferable if there were a way for OFW to do
a bulk erase of the device before starting the installation.  (of
course, if OFW could do a bulk erase, it could probably also do a
bulk write, meaning it could perhaps continue working much as it
does today.)

paul
=---------------------
 paul fox, pgf at laptop.org