Bill, please stop for a moment and tell yourself "this argument isn't
about what *I* want.   It's about what NetBSD users in general want."
This statement is true about anything one might consider putting into
NetBSD.   I know it's been used on me more than once!   :')

> And that it was not designed for what a lot of people are wanting it to do
> - be a kitchen sink respository.

Right.   It was designed to solve exactly one problem: yours.   That's
the problem with the design, in a nutshell.   Your problem is a
reasonable and valid problem - don't get me wrong.   But you've added
a general machanism that isn't actually general, and now you're
getting pushback.

> Also, performance is a BIG issue for what we want to do. We are
> looking at 7x24 systems with Terrabytes of storage and thousands of
> users, probably acting as NFS servers. The thought of handling
> variable-length data in this environment concerns me.

I don't see how this would be a problem.  Because your application is
as specialized as it is, it should be easy to arrange for your data to
come first, and just do a sanity check to make sure it did.  The
performance impact of supporting more than one data hunk in the opaque
data buffer should be negligible for your application if you do it
this way.   You get what you want, and you don't preclude other
applications of the API.

> I think it's fine to extend the interface a bit. Right now we have test,
> get, set, and clear operations on the metadata. It seems easy to me to
> extend them to take a magic number value, with (0) being the catch-all. So
> then you can deal with different types of data, and even add an overlay fs
> to store multiple types at once.

Why not just do it right, so that we don't have to have people mount
an overlay filesystem to get the correct (that is, general) behaviour
later?

> Granted. Though we would like to keep things easy to export to other
> systems. Does the fcntl call in general have the functionality we need
> (pass a file descriptor, a command which encodes in/out access, and a void
> *) on other/most platforms?

AFAIK, the F_GETLK/F_SETLK call is in POSIX, and that's functionally
the same as what you're talking about.

> That's fine. But since it'll take time to hash all these things out, we
> decided to go with the flag field to say what is there. That way not
> everything has to be decided at once.

Once features have gone in, they can't come out.   Your proposed
change is will not be compatible with the general solution, so if we
are ever going to implement the general solution, we have to do it
now.   Having a flags field won't help.

> About (1), most of the proposals have solved a different problem than the
> one we have in mind.

Right, and that's what's wrong with your proposal.   Making a major
change to the kernel that purports to be generic but in fact is not is
a mistake.   If you don't want it to be generic, you should simply
reserve the space you need for your application and duke it out that
way.   If you can't justify doing it that way, you also can't justify
doing what you're currently doing.

> Actually, given that the vnextops or fcntl command
> space would have at least 16k worth of generic commands, we could
> certainly later on add commands which deal with tag/length data. :-)

The problem is not the API.   The problem is the underlying data
structure.   If we do the underlying data structure wrong, a future
change to the API will not cure the problem.

			       _MelloN_