Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: VFS EA interface patch (was: A modest proposal...) | Date | Wed, 6 Feb 2002 11:52:37 +0100 |
| |
On February 6, 2002 11:35 am, Anton Altaparmakov wrote: > 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.
There's always a namespace string and an attribute name string? That sounds like two parameters to me, why are they being passed as one.
> >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.
I'm did not miss that. Why do you want glibc, or worse, user tools, doing extra ascii smashing to build up the ea string in the format the kernel interface wants.
> >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?
Namespaces are good. I don't like the syntax being built into the name. This is every bit as wrong as the thing Al complained about, creating more system calls by passing in a function number.
If there are two strings, pass two strings.
-- Daniel - 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/
| |