lkml.org 
[lkml]   [2002]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: VFS EA interface patch (was: A modest proposal...)
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.069 / U:15.164 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site