> But on the flip side we also seem to have moved towards a policy where if
> you're going to raise the bar on what has to be done, you have to be
> willing to deliver on what you've asked for. :-)

I don't have lots of hours to spare, but I can easily spare one to
write the code for this.

> Though our problem guided the design, it is a general solution. It's just
> not a solution to the general problem you're proposing. :-) Nor does it
> claim to be. It claims to be a solution to the problem of overly fs's
> needing a small amount of per-inode storage.

No, it is _not_ a solution to that problem, because it only works if
you have one such filesystem.   The minute that you have two, it stops
working.   So it's a solution to your problem, and your problem alone.
As soon as somebody else tries to use it, all bets are off.

> Because to satisfy the fully general case means sticking a database in the
> filesystem. That strikes me as HARD. Actually, sticking a database into
> the inode!

No, the fully general case means having a buffer with tags and
lengths, and some code to add and remove such tags, and to fetch them.
This is _trivial_.  Take a look at nfs_bootdhcp.c for an example
implementation (admittedly with 8-bit tags, not 24-bit tags).

> Also, it strikes me as wrong. The database management should sit above the
> fs, not in it. Even Apple did it that way - there's a resource fork which
> the resource manager turns into all the fun little resources MacOS
> programmers have grown to love. ;-)

I'm sorry that it strikes you as wrong.   I don't see any way to fix
that.   Since the resources can be used within the kernel, kernel code
has to parse them.

> And there's the fact that I don't see a problem which needs this
> kitchen-sink solution. :-)

I'm also sorry that you see this as a kitchen-sink solution.   You
must live in a New York apartment like I do.

> Yes, it will. Because there's nothing saying that the presence of other
> flags can't preclude the use of the opaque data we're proposing. :-) 

Oh come on.

> Since our solution is an overlay fs, we can't reach into the ffs inode.
> ffs (or lfs) has to have a way to give us this info. To do otherwise is an
> even larger hack.

If you're going to make a pervasive change, do it right.   I agree
with your decision not to do a grody hack for this.   I disagree with
your desire to underspecify your hack to the point where it's only
useful for you.

> Not true. An API which supports variable length storage can just pick up
> these ops as implicitly refering to 96-byte blobs.

Right, and people implementing to the API will have to assume that
their code will not run at NASA/Ames or any other site that deploys
your application code (the tertiary storage stuff).  This seems like a
pretty big problem to me.

Bill, I've proposed a way to do TRT with no additional space used in
the opaque data field.   Other than epithets like "kitchen sink,"
what's your problem with this?   Why are we still arguing about this?

			       _MelloN_