Re: [PATCH] Draft for xattr support

[leslie . polzer]

[taking this to bug-findutils]


On Wed, Apr 04, 2007 at 10:40:05AM +0100, James Youngman wrote:

> I'm not sure what the relative performance cost is of the functions
> get_attr() and so forth. I would not be surprised to see that they
> were about as fast as access(), perhaps a little slower. So I guess
> this needs an entry in "enum EvaluationCost".

Noted.


> The ext2 filesystem also supports attributes on both Linux and Hurd.
> If we are going to support extended attributes, it would be worth
> designing it in such a way that the same predicate can (unambiguously)
> be used for other types of extended attributes.

I'm going to think about a good way of designing this.  For the moment,
I will stick with the NAME=VALUE syntax (only) for XFS-style attributes
(which are the same as ReiserFS xattr and ext2/3 user_xattr), which
shouldn't be a problem WRT ambiguity.

The second type, by the way, are ext2/3 attributes (note the absence of
'extended' here).  Maybe a second switch is warranted.  Or a name change
of 'xattr' -> 'attr'.  I'm going to think about it, as I said :)


> Lastly, I think this discussion should include the bug-findutils
> mailing list, so that others can participate in the design process.
> OK?

I hope this effect will take place! :)

  Leslie


-- 
NEW homepage: https://viridian.dnsalias.net/~sky/homepage/
gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83

pgpaIg084YT9t.pgp
Description: PGP signature