From: Nathan Scott <nathans@sgi.com>
To: Alexander Viro <viro@math.psu.edu>, Andi Kleen <ak@suse.de>,
Andreas Gruenbacher <ag@bestbits.at>,
Linus Torvalds <torvalds@transmeta.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-xfs@oss.sgi.com
Subject: Re: [RFC][PATCH] VFS interface for extended attributes
Date: Fri, 16 Nov 2001 10:18:00 +1100 [thread overview]
Message-ID: <20011116101800.A632931@wobbly.melbourne.sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0111121152410.14344-100000@moses.parsec.at> <Pine.GSO.4.21.0111121207530.21825-100000@weyl.math.psu.edu> <20011113062711.A1912@wotan.suse.de> <20011115160853.N588010@wobbly.melbourne.sgi.com> <20011114230134.A5739@lynx.no>
In-Reply-To: <20011114230134.A5739@lynx.no>; from adilger@turbolabs.com on Wed, Nov 14, 2001 at 11:01:34PM -0700
hi Andreas,
On Wed, Nov 14, 2001 at 11:01:34PM -0700, Andreas Dilger wrote:
> On Nov 15, 2001 16:08 +1100, Nathan Scott wrote:
>
> > + int (*create) (struct inode *, char *, void *, size_t);
> > + int (*replace) (struct inode *, char *, void *, size_t);
> > + int (*set) (struct inode *, char *, void *, size_t);
>
> What is the distinction between "set" and "replace" or "set" and "create"?
>
+#define EA_CREATE 0x0001 /* Set the value: fail if attr already exists */
+#define EA_REPLACE 0x0002 /* Set the value: fail if attr does not exist */
Whereas "set" is simply set the named attribute value, creating the
attribute if need be, replacing the value if the attribute exists,
and then return success.
The man pages on AndreasG's site go into more detail, but decribe
the original interface which Al didn't like. I haven't created an
updated man page yet, because I'm still not sure if this interface
is quite what Al was looking for either... (Al?)
> ... why are there not just
> flags to distinguish the two, but also separate VFS operations?
A VFS flags parameter could allow an individual filesystem to extend
the semantics of the set operation in new ways by adding new flags -
I think Al wanted to avoid the possibility of that ever happening,
which seems fair enough.
cheers.
--
Nathan
next prev parent reply other threads:[~2001-11-15 23:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-10 9:08 [RFC][PATCH] " Tim R.
2001-11-11 10:50 ` Nathan Scott
2001-11-12 1:57 ` Anton Altaparmakov
2001-11-12 3:20 ` Nathan Scott
2001-11-12 6:21 ` [RFC][PATCH] VFS interface for " Nathan Scott
2001-11-12 6:47 ` Alexander Viro
2001-11-12 11:39 ` Andreas Gruenbacher
2001-11-13 0:32 ` Alexander Viro
2001-11-13 5:27 ` Andi Kleen
2001-11-15 5:08 ` Nathan Scott
2001-11-15 6:01 ` Andreas Dilger
2001-11-15 23:18 ` Nathan Scott [this message]
2001-12-03 0:07 ` Daniel Phillips
2001-12-03 0:54 ` Nathan Scott
2001-12-03 14:52 ` Daniel Phillips
2001-12-03 23:14 ` Nathan Scott
2001-11-13 0:47 ` Anton Altaparmakov
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=20011116101800.A632931@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=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
all inboxes | Powered by JetHome®