linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nathan Scott <nathans@sgi.com>
To: Daniel Phillips <phillips@bonn-fries.net>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Alexander Viro <viro@math.psu.edu>, Andi Kleen <ak@suse.de>,
	Andreas Gruenbacher <ag@bestbits.at>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-xfs@oss.sgi.com
Subject: Re: [PATCH] Revised extended attributes interface
Date: Fri, 7 Dec 2001 14:51:31 +1100	[thread overview]
Message-ID: <20011207145131.B54252@wobbly.melbourne.sgi.com> (raw)
In-Reply-To: <20011205143209.C44610@wobbly.melbourne.sgi.com> <E16C0PD-0000ot-00@starship.berlin> <20011207101517.B46546@wobbly.melbourne.sgi.com> <E16CAMb-0000s1-00@starship.berlin>
In-Reply-To: <E16CAMb-0000s1-00@starship.berlin>; from phillips@bonn-fries.net on Fri, Dec 07, 2001 at 03:03:43AM +0100

hi Daniel,

On Fri, Dec 07, 2001 at 03:03:43AM +0100, Daniel Phillips wrote:
> On December 7, 2001 12:15 am, Nathan Scott wrote:
> > > > [extended attributes on symlinks]
> > >   get, fget, set, fset, del, fdel, list, flist
> > 
> > I'm not too fussed - the second draft patch I sent out did exactly
> > as you describe, in an attempt to cut down on syscalls.  This again
> > meant adding a "flags" field to each operation.  We also have stat/
> > lstat/fstat and chown/lchown/fchown - I was trying to be consistent
> > with those, and I still think that is the right thing to do.
> 
> It may well be, however, the one call that has flags, set, is looking a 
> little irregular sitting there on its own.

Not sure what to say to that ... the API is practical, flags
seem to make sense for that call (the flags give the slightly
different "set" semantics, but it is still "set"), IMO they
don't make sense for others.

> We're inventing an API here for which we don't have a lot of guidance from 
> existing unices, correct?

No.  Many existing versions of Unix support extended attributes
in some form or another, but there is no common API/standard -
each implementation differs, sometimes radically, to the others.

> It wouldn't hurt to really kick it around.

Please read the archives first - discussion started well over a
year ago now on an API for Linux, and there have been heaps and
heaps of ideas, proposals, prototypes, etc, floated.

The lack of progress on getting something in the kernel is
hurting several projects (even having syscalls reserved would
be a _huge_ help to us).  We have distributors telling us they
would include XFS in their kernels if there was some progress
on this particular issue.

> After all, what we settle on in Linux is likely to become the standard.

Mmm.. I seriously doubt there could ever be any standards in this
area - I would be satisfied with a good implementation on Linux,
which allows filesystems from different operating systems to use
it while preserving any existing on-disk formats they may have.

> 
> Presumably there's some existing practice at SGI, do you have a pointer to 
> man pages?
> 

Start with the mail we sent to Linus, LKML, fs-devel, etc about a
month ago - it had pointers to the original discussion from this
time last year (and in that discussion, Andreas provided pointers
to documentation for several other implementations, incl. BSD,
IRIX, Tru64, & others).  It also has pointers to several projects
relying on the existing, diverging Linux implementations.

It should probably be pointed out again that many of the folk
working on filesystems which support extended attributes have
given their collective thumbs up to the latest round of patches.
In particular, the projects which have already implemented EAs
(XFS, ext2/ext3) and services above EAs, are confident that
these patches will work for them and that we'll be able to get
our userspace code working together for the first time.

cheers.

-- 
Nathan

  reply	other threads:[~2001-12-07  3:53 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-05  3:32 [PATCH] Revised extended attributes interface Nathan Scott
2001-12-05  9:08 ` Anton Altaparmakov
2001-12-06  5:46   ` Nathan Scott
2001-12-06  3:05 ` Daniel Phillips
2001-12-06  5:41   ` Nathan Scott
2001-12-06 15:25     ` Daniel Phillips
2001-12-06 23:15       ` Nathan Scott
2001-12-07  1:45         ` Daniel Phillips
2001-12-07  2:03         ` Daniel Phillips
2001-12-07  3:51           ` Nathan Scott [this message]
2001-12-07 20:20 ` Stephen C. Tweedie
2001-12-08  4:58   ` Nathan Scott
2001-12-08 20:17     ` Hans Reiser
2001-12-11  2:42       ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Nathan Scott
2001-12-11 12:02         ` Hans Reiser
2001-12-11 19:23         ` Anton Altaparmakov
2001-12-11 20:14           ` reiser4 (was Re: [PATCH] Revised extended attributesinterface) curtis
2001-12-11 21:34             ` Hans Reiser
2001-12-11 23:04               ` curtis
2001-12-11 23:28                 ` Hans Reiser
2001-12-11 23:46                   ` Anton Altaparmakov
2001-12-12  1:00                   ` curtis
2001-12-11 21:21           ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Hans Reiser
2001-12-11 23:33             ` Anton Altaparmakov
2001-12-11 23:59               ` Hans Reiser
2001-12-12  2:16                 ` Anton Altaparmakov
2001-12-12 12:02                   ` Hans Reiser
2001-12-12 13:34                   ` Anton Altaparmakov
2001-12-12 15:40                     ` Hans Reiser
2001-12-13  1:43             ` Andrew Pimlott
2001-12-13  9:23               ` Hans Reiser
2001-12-13 10:36                 ` User-manageable sub-ids proposals Romano Giannetti
2001-12-13 13:37                   ` Ragnar Kjørstad
2001-12-13 16:06                     ` Romano Giannetti
2001-12-13 18:58                       ` Ragnar Kjørstad
2001-12-18  0:17                     ` Pavel Machek
2001-12-13 23:24                   ` David Wagner
2001-12-21 21:28                   ` Andreas Ferber
2001-12-13 15:27                 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Andrew Pimlott
2001-12-13 20:47                   ` Hans Reiser
2001-12-13 21:01               ` Anton Altaparmakov
2001-12-10 11:52     ` [PATCH] Revised extended attributes interface Stephen C. Tweedie
2001-12-10 15:00       ` Peter J. Braam
2001-12-10 15:56         ` Stephen C. Tweedie
2001-12-10 16:00           ` Mr. James W. Laferriere
2001-12-10 16:15             ` Stephen C. Tweedie
2001-12-10 19:01           ` John Stoffel
2001-12-11  1:22       ` Timothy Shimmin
2001-12-11 11:33         ` Stephen C. Tweedie
2001-12-11 15:15           ` Implementing POSIX ACLs - was: " Anton Altaparmakov
2001-12-11  1:41       ` Nathan Scott
2001-12-11 13:47         ` Stephen C. Tweedie
2001-12-11 18:23           ` Hans Reiser
2001-12-11 18:46           ` Anton Altaparmakov
2001-12-11 23:37           ` Implementing POSIX ACLs - was " Nathan Scott
2001-12-11 13:30       ` Implementing POSIX ACLs - was: " Anton Altaparmakov
2001-12-11 14:34         ` Stephen C. Tweedie

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=20011207145131.B54252@wobbly.melbourne.sgi.com \
    --to=nathans@sgi.com \
    --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=phillips@bonn-fries.net \
    --cc=torvalds@transmeta.com \
    --cc=viro@math.psu.edu \
    /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).