On 06/21/2010 07:21 PM, James Morris wrote:
On Mon, 21 Jun 2010, Chuck Lever wrote:
+#define NFS_XATTR_PROGRAM 391063 /* TODO: find another value */
RFC 5531, appendix B proscribes the appropriate method for requesting an RPC
program number assignment.
Even though the NFSACL protocol doesn't have one, I have to agree with Deniel
that we should have the RPCL definition of the on-the-wire protocol first, so
we can review it and ensure our user space and kernel XDR functions remain
consistent and correct over time.
Indeed, this is something I'm hoping to do soon.
Is there an RFC?
No, there have been several implementations, but never an RFC for xattrs.
I'm using the XFS implementation as a starting point, and following the
ACL model of implementing a side-protocol.
Especially if we expect non-Linux implementations, I would think an
IANA-assigned program number and a proper RPCL definition would be apriori
requirements.
It's possible the FreeBSD folk may want to interop with this, as they have
similar name/value xattrs.
This is why apriori documentation (such as an internet RFC or similar
that describes the wire protocol) is important. For an example of a
side band protocol description, you can look at RFC 1094 or RFC 1813 and
look at the sections that describe the MOUNT and NLM protocols.
Another place to look is at NFSv4. Some of the operations that can be
performed on NFSv4 xattrs are probably nearly what you would want for an
NFSv3 implementation. I think it is desirable for anything done for
NFSv3 to be compatible with NFSv4, as that is already a standard.
(Btw, slides from a presentation I did on this last year at LinuxCon are
at http://namei.org/presentations/linuxcon09_nfsv3xattrs.pdf)
NFSACL was added to our NFSv3 implementation because there was a desire
to interoperate with an existing (albeit nonstandard) implementation.
Here you are building a new side band protocol from scratch.
Before you go too much farther, you should justify the need to enhance a
closed standard like NFSv3 rather than expanding on NFSv4 for your
purposes. Since NFSv4 already has a lot of what is needed, it seems
like you'd just need a couple of changes in order to support name/value
pairs. You would have a shot at actually making this an internet standard.
I think this community would prefer to advance reasons for users to
adopt NFSv4, rather than tie users even more to NFSv3.
--
Chuck Lever
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
