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/