Re: A memory-based filesystem for the lazy [or impatient]

[Roland McGrath]

> The other thing I can think of is an option --init to translators which
> means "initialize the store at start up". Is this more acceptable?

I'm not sure precisely what you are suggesting here, so I don't have an
opinion.

> That's a clever thing to do, but it doesn't solve the general problem of
> initialization of transient stores. In general, we want to avoid boot
> script magic, and we can in this case. The one thing I suggested was to
> a "run" store type which passes through a store after initialization.

The more I think about this the more it seems like probably the right thing
conceptually.  The "transient" store types we have now are zero, copy,
gunzip, and bunzip2.  For all of these there is an initialization-time
step, which is built-in to the store type.  copy, gunzip, and bunzip2 are
all the same after initialization (they could be thought of as the "buffer"
or "memory" store type), so the only real meaning of those store type is
their initialization action.  So I think it is reasonable to use a store
type to indicate the special initialization you want to do.

What it is reasonable to implement in terms of a general "run this command"
kind of initialization action is another story.  libstore does not (and
should not) provide an io server like storeio by which another process
could access an arbitrary store opened by the filesystem (or whatever
libstore-using process it is).  So I think the thing to do is to have the
command produce the initialized contents somehow to be inserted directly as
the store_copy_class store's buffer, perhaps through a pipe.  Make a "copy
of stdout" store type, e.g.
        /hurd/ext2fs -Tstdout "mke2fs -f /dev/stdout 204800"
and opening the store would run the command (store name) with popen (don't
actually use popen), collecting the output into a buffer and fixing the
size of the store when the pipe got EOF.