xfs
[Top] [All Lists]

Re: attr cleanups

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: attr cleanups
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 6 May 2014 06:55:52 +1000
Cc: Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <53679113.8000209@xxxxxxx>
References: <1399130415-5382-1-git-send-email-hch@xxxxxx> <53651375.9080305@xxxxxxx> <20140504101623.GA4947@xxxxxx> <53679113.8000209@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>