public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Nathan Scott <nathans@sgi.com>
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.comc
Subject: Re: [RFC][PATCH] extended attributes
Date: Wed, 7 Nov 2001 02:32:18 +0100	[thread overview]
Message-ID: <20011107023218.A4754@wotan.suse.de> (raw)
In-Reply-To: <20011107111224.C591676@wobbly.melbourne.sgi.com>
In-Reply-To: <20011107111224.C591676@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Nov 07, 2001 at 11:12:24AM +1100

On Wed, Nov 07, 2001 at 11:12:24AM +1100, Nathan Scott wrote:
> A manual page describing the system call interface can be found here[4].
> We're very interested in feedback on this.  In partiular, Linus - would

The cursor support looks quite complicated. It doesn't even forbid 
storing the contents of the cursor buffer somewhere and has all
the standard problems with stateless cursors requiring nasty hacks
with dynamic data structures with parallel modification.
Stateless cursors are just nasty!

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.

It would not be inherently thread safe, but also not be worse
in this regard than standard readdir (requiring user locks)

It would also be possible to do a threadsafe interface although it would be 
a bit uglier: EA_GET_LISTSIZE to get the 
size of the buffer required, EA_GET_FULL_LIST to fetch a full
buffer with the names of all EAs, EAGAIN on race.

I think doing it in one of these ways would be far easier for the
user and easier for future kernel implementations.

-Andi

  parent reply	other threads:[~2001-11-07  1:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-07  0:12 [RFC][PATCH] extended attributes Nathan Scott
2001-11-07  0:23 ` Nathan Scott
2001-11-07  1:32 ` Andi Kleen [this message]
2001-11-07  1:38   ` Alexander Viro
2001-11-07  3:19   ` Nathan Scott
2001-11-08  1:26     ` [Acl-Devel] " Stephen Tweedie
2001-11-08  6:48     ` Andi Kleen
2001-11-12  5:01   ` Nathan Scott
  -- strict thread matches above, loose matches on Subject: below --
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=20011107023218.A4754@wotan.suse.de \
    --to=ak@suse.de \
    --cc=acl-devel@bestbits.at \
    --cc=ag@bestbits.at \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.comc \
    --cc=nathans@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