From: Christoph Hellwig <hch@lst.de>
To: Timothy Shimmin <tes@sgi.com>
Cc: Christoph Hellwig <hch@lst.de>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] use generic_*xattr routines
Date: Thu, 29 May 2008 14:39:10 +0200 [thread overview]
Message-ID: <20080529123910.GA30874@lst.de> (raw)
In-Reply-To: <483BE788.4050504@sgi.com>
On Tue, May 27, 2008 at 08:50:48PM +1000, Timothy Shimmin wrote:
> > - the callback is supplied by the xfs_attr_list caller, not set based
> > on options
>
> Oh, okay. For example, instead of setting the flags to ATTR_KERNOVAL
> such as in xfs_vn_listxattr when size is 0, one could just set the callback
> to xfs_attr_kern_list_sizes and pass it in etc...
Yes. I have an initial patch that goes directly to xfs_attr_list_int
from xfs_xattr.c and kills most of the ATTR_KERN flags. It's a quite
nice cleanup already. Next step will be to convert dmapi to use it's
own callback aswell. This will be an even bigger cleanup as
put_listent gets the xattr value aswell and we can kill the additional
xfs_attr_get calls, making this code simpler and more efficient.
> > - there will be an opaque object supplied to xfs_attr_list that is to
> > be used by put_listent so that we don't have to pass down
> > implementation-specific arguments directly.
> >
>
> Ok.
> So instead of overloading fields in xfs_attr_list_context_t,
> you'll pass down a void* argument or some such for callback specific data.
I've started looking at this and after some investigattion I think
we should just pass the xfs_inode directly to all the functions and then
a void parameter, yes. We'll need to find a solution for the
seen_enough paramter, but I think this could be handled similar to
filldir. There's also some functions directly touching the attr cursor
which seems solveable, too.
> > I'd also like to move the attrlist_cursor_kern_t into this callback
> > opaque context because it doesn't make sense for the normal xattr API,
> > but I'll have to see if that's actually feasible.
>
> BTW, the cursor stuff is a bit flawed. Like the dir1 code (I believe),
> if from userspace you use the cursor and modifications happen to the EAs
> (add or removal) between calls,
> we can end up repeating elements in the list or miss some.
> We don't preserve the position and we can compact the data etc.
Yes, I think this whole cursor is a rather bad idea. But given that
it's used by xfsdump we can't easily get rid of it.
next prev parent reply other threads:[~2008-05-29 12:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-30 11:22 [PATCH] use generic_*xattr routines Christoph Hellwig
2008-05-21 8:16 ` Christoph Hellwig
2008-05-22 7:17 ` Timothy Shimmin
2008-05-23 5:22 ` Timothy Shimmin
2008-05-23 5:48 ` Christoph Hellwig
2008-05-26 1:43 ` Timothy Shimmin
2008-05-26 5:37 ` Christoph Hellwig
2008-05-27 10:50 ` Timothy Shimmin
2008-05-29 12:39 ` Christoph Hellwig [this message]
2008-05-30 6:37 ` Timothy Shimmin
2008-05-30 7:53 ` 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=20080529123910.GA30874@lst.de \
--to=hch@lst.de \
--cc=tes@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