> > Well, I'd argue that Berkeley defined a bunch of VFS attributes, and
> > then implemented them natively in UFS and LFS; other non-native
> > filesystems have to map their concepts of other file attributes (e.g.,
> > dates, permissions, etc.,) into the native VFS concepts.
> 
> 	Right. Except that UFS has not only generic attibutes. For example,
> you have UF_NODUMP and SF_ARCHIVED. The *only* place in the /sys you
> mention the former is sys/stat.h (BTW, you don't even map it on
> EXT2_NODUMP_FL). The latter is mentioned only in the msdosfs/msdosfs_vnops.c.
> Hardly a VFS flag, right?

It sounds like the implementation is what you are complaining about here,
not the design or the interface.

If I understand you correctly, the level argument in the proposed API is
used to extend the namespace for the attributes.  Do you see a real need
right now to extend your namespace this way?  It seems to provide more
room for error on the programmer's side by increasing the complexity
(albeit not much) of the function/system call.

Additionally, using the same name as the BSD entry point but changing the
calling conventions could confuse programmers who use both systems and
even if it doesn't confuse them, it's an additional thing that they have
to keep in mind when writing portable software.  I think we should be
working in the other direction--reducing the differences between the
systems and making it easier to write portable software.  Maybe that's
just me, though...  ;-)

-allen