Re: VFS EA interface patch (was: A modest proposal...)

From: Anton Altaparmakov (aia21@cam.ac.uk)
Date: Wed Feb 06 2002 - 05:35:16 EST


At 04:08 06/02/02, Daniel Phillips wrote:
[snip]
>My main problem with the EA interface patch itself is that there is no
>way to specify the class of the EA, currenly 'system' or 'user'.
>Instead, individual filesystems are expected to parse the attribute
>name to determine the class. I think this is inadequate, and has not
>been discussed sufficiently.

Have you read those:
         http://acl.bestbits.at/man/extattr.5.html
         http://acl.bestbits.at/man/extattr.2.html

Why is this inadequate? The above specify perfectly well what the current
defined EA namespaces are, and the API is extensible in that should people
come up with other useful namespaces (I can't think of any) they can just
be added without any modification to the generic EA interface in the kernel
and that is good.

NTFS for example has no concept of different EA classes and I am planning
to only support the "user." namespace and just adding "user." before
returning an EA and removing it when writing an EA. All other classes will
just return that such beasts are not supported.

>What will happen is, user space utilities will start making assumptions
>about the syntax of ea names (because the kernel interface provides no
>other alternative) and the current, arbitrary, EA name syntax will become
>cast in stone for ever more.

A binary interface is much worse. While with the current interface it is
arbitrary, at least it is defined, so yes, it is set in stone for ever
more, and that is a Good Thing, you don't want to be changing that in the
future.

However you are missing a very important point and that is that this is the
EA API for the kernel. There is nothing to stop glibc (or some EA library)
defining whatever different interface they like and exposing that to user
space.

>Then attribute classes will start to multiply, we'll get attribute
>namespaces, and we'll get more arbitrary hacks added to the attribute name
>syntax to accomodate them. Support for 'new, improved' attribute name
>syntax will be variable across filesystems. This isn't going to be pretty.

I don't see why any of this should happen. The interface for EAs is well
defined in the above referenced documents. And note that we already have
attribute namespaces, that is the whole point of the "user.", "system.",
etc. That is what is used to distinguish the various classes. Or did I miss
your point completely?

Best regards,

Anton

-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:48 EST