mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nathan Scott <nathans@sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Andreas Gruenbacher <ag@bestbits.at>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	acl-devel@bestbits.at, linux-xfs@oss.sgi.com
Subject: Re: [RFC][PATCH] extended attributes
Date: Wed, 7 Nov 2001 14:19:56 +1100	[thread overview]
Message-ID: <20011107141956.F591676@wobbly.melbourne.sgi.com> (raw)
In-Reply-To: <20011107111224.C591676@wobbly.melbourne.sgi.com> <20011107023218.A4754@wotan.suse.de>
In-Reply-To: <20011107023218.A4754@wotan.suse.de>; from ak@suse.de on Wed, Nov 07, 2001 at 02:32:18AM +0100

hello again Andi,

On Wed, Nov 07, 2001 at 02:32:18AM +0100, Andi Kleen wrote:
> I think it would be better to have a statefull readdir instead.
> The kernel supports it via the ->private_data field of struct file
> (not through fork,but that looks like a generic vfs bug) 
> 
> EA_FIRST_ENTRY to reset the fd the first entry, EA_READ_ENTRY to 
> read the next one.

I'm not sure this would work for the extattr/lextattr variants where
we don't have an fd to hold the state.  Should the list operation
be restricted to the fextattr variant, perhaps?  I'm not sure about
all the implications of that, will have to see what everyone else
thinks I guess.

eg. the opening of the file before allowing a list operation could
have implications for XFSs DMAPI support (open might recall data from
tape), where the management tools need to be able to list these DMAPI
related attributes without affecting the backing storage, I believe -
I'll have to ask some DMAPI gurus about that one though.

Thanks for the input.

cheers.

-- 
Nathan

  parent reply	other threads:[~2001-11-07  3:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-07  0:12 Nathan Scott
2001-11-07  0:23 ` Nathan Scott
2001-11-07  1:32 ` Andi Kleen
2001-11-07  1:38   ` Alexander Viro
2001-11-07  3:19   ` Nathan Scott [this message]
2001-11-08  1:26     ` [Acl-Devel] " Stephen Tweedie
2001-11-08  6:48     ` Andi Kleen
2001-11-12  5:01   ` Nathan Scott
2001-11-08 16:12 Luka Renko
2001-11-08 16:29 ` Andreas Gruenbacher
2001-11-08 16:47 Dean Roehrich
2001-11-10  9:08 Tim R.
2001-11-11 10:50 ` Nathan Scott
2001-11-12  1:57 ` Anton Altaparmakov
2001-11-12  3:20   ` Nathan Scott

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=20011107141956.F591676@wobbly.melbourne.sgi.com \
    --to=nathans@sgi.com \
    --cc=acl-devel@bestbits.at \
    --cc=ag@bestbits.at \
    --cc=ak@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=torvalds@transmeta.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

all inboxes | Powered by JetHome®