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/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:48 EST