From: Dave Chinner <david@fromorbit.com>
To: Mark Tinguely <tinguely@sgi.com>
Cc: Christoph Hellwig <hch@lst.de>, xfs@oss.sgi.com
Subject: Re: attr cleanups
Date: Tue, 6 May 2014 06:55:52 +1000 [thread overview]
Message-ID: <20140505205552.GX26353@dastard> (raw)
In-Reply-To: <53679113.8000209@sgi.com>
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@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-05-05 20:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-03 15:20 attr cleanups Christoph Hellwig
2014-05-03 15:20 ` [PATCH 1/5] xfs: fold xfs_attr_set_int into xfs_attr_set Christoph Hellwig
2014-05-05 20:21 ` Brian Foster
2014-05-03 15:20 ` [PATCH 2/5] xfs: fold xfs_attr_get_int into xfs_attr_get Christoph Hellwig
2014-05-05 20:21 ` Brian Foster
2014-05-03 15:20 ` [PATCH 3/5] xfs: fold xfs_attr_remove_int into xfs_attr_remove Christoph Hellwig
2014-05-05 20:21 ` Brian Foster
2014-05-05 20:56 ` Dave Chinner
2014-05-05 21:08 ` Brian Foster
2014-05-03 15:20 ` [PATCH 4/5] xfs: simplify attr name setup Christoph Hellwig
2014-05-05 20:21 ` Brian Foster
2014-05-03 15:20 ` [PATCH 5/5] xfs: pass struct da_args to xfs_attr_calc_size Christoph Hellwig
2014-05-05 20:21 ` Brian Foster
2014-05-06 8:06 ` [PATCH 5/5 v2] " Christoph Hellwig
2014-05-06 9:09 ` Dave Chinner
2014-05-03 16:04 ` attr cleanups Mark Tinguely
2014-05-04 10:16 ` Christoph Hellwig
2014-05-04 21:52 ` Dave Chinner
2014-05-05 13:24 ` Mark Tinguely
2014-05-05 20:55 ` Dave Chinner [this message]
2014-05-06 19:40 ` Mark Tinguely
2014-05-06 20:51 ` Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2023-12-17 17:03 Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140505205552.GX26353@dastard \
--to=david@fromorbit.com \
--cc=hch@lst.de \
--cc=tinguely@sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).