On 05/05/14 15:55, Dave Chinner wrote:
On Mon, May 05, 2014 at 08:24:35AM -0500, Mark Tinguely wrote:
On 05/04/14 05:16, Christoph Hellwig wrote:
On Sat, May 03, 2014 at 11:04:05AM -0500, Mark Tinguely wrote:
Depends on how parent inode pointers are implemented, this folding the
internal version of get and set attributes could be undone.
We might have to introduce _locked version at that point. But I'd like
to keep the xfs_name removal and other assorted cleanups.
locking is only one issue, xfs_attr_(get/set/remove) are asciii only
whereas the xfs_attr_(get/set/remove)_int versions are more generic.
I am thinking of not just parent inode pointers but a non-ascii
character set.
I fail to see how they are different. The attribute name is just an
opaque binary blob - only when it is compared externally does it
have any meaning at all.
Character sets are meaningless unless you are doing case
manipulation, in which case we would need to apply the same
treatment as the directory code deep in the internal attribute cod.
i.e It needs case aware compare and hash algorithms. However, the
outer layers are completely unchanged - they just pass through the
blob that was passed to them...
Cheers,
Dave.
Right now xfs_attr_get(), xfs_attr_set, xfs_attr_remove() expect the
name to be a NULL terminate character array.
The internal versions of these functions have a more useful interface,
they use a blob for the name (the array/length xfs_name structure).
--Mark.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
