Something like:
int whefs_fs_meta_set( whefs_fs *, char const * key, char const * val );
this could be used to add, e.g., publisher or license info. The problem is
we'd need a set size for the records. Another idea would be to store the
data in inode 0, but that would require that some (much) other code handle
that special case. We could also reserve the last inode for this purpose,
but then we (or the user) also needs to reserve a data space for this.
i've been working on a whio_dev-based btree, which we could use on top of a
pseudofile to store this data. It's basically working but the way it saves
its records is way too low-level, as it writes the blocks directly to the
device without any sort of encoding. That means a little-endian-written
version can't be read by a big-end efs. That would be bad. If i can get
that fixed (the code its based on is hard to follow and change, as it's so
low-level), i could use that to trivially add a user-managed btree of
key/val pairs.
But until then... just another feature to think about.
Original issue reported on code.google.com by sgbeal@googlemail.com on 1 Dec 2009 at 9:54
Original issue reported on code.google.com by
sgbeal@googlemail.com
on 1 Dec 2009 at 9:54