attr cleanups

[Mark Tinguely]

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.