> One, the big one, is that we're now building something close to the
> resource manager into the fs.

You're building something that knows how to insert and delete tagged
hunks of data from a buffer.   This is not complicated.

> Second reson: One of the big points of the opaque data standard so far is
> that magic numbers are reserved both forward and byte-swapped.

Right, and there's no need to do this.   Store the data in network
byte order, and the problem goes away.   Even if you don't do this for
the inode data itself, there's no reason not to do it for the magic
number.   It's certainly not a reason not to implement a more general
solution than the one you've proposed.

> It's not easy to do though, and easier to get wrong. :-)

I am assuming you're kidding about this, right?  Implementing what
I've proposed, in the grand scheme of kernel hacks, is right up there
with implementing strcpy.   It's a lot less difficult than the system
you're building on top of this small change we're arguing about.

> Note also that if you're REALLY using overlay fs's in a production
> environment, you have to shield users from the underlying layers, and
> you'll really have to think about things before you set them up. So we
> don't have to make a everything-and-kitchen-sink solution. :-)

The fcntl call is going to descend through the filesystem stack.  If
your filesystem layer doesn't want userland mucking with its data, it
can simply return ENOENT when asked for the data associated with its
magic number.  Adding something to a filesystem everybody uses for an
application only you use is going to suck for everybody else, and
that's why I'm proposing making it more general.  IMHO, you really
have a choice between making it general, or not doing it at all.
Doing things the way you currently propose doesn't seem like a viable
choice to me.

			       _MelloN_