From: "NeilBrown" <neilb@suse.de>
To: "Chuck Lever III" <chuck.lever@oracle.com>
Cc: "Bruce Fields" <bfields@fieldses.org>,
"Linux NFS Mailing List" <linux-nfs@vger.kernel.org>,
"Christoph Hellwig" <hch@lst.de>
Subject: [PATCH 1/3 v3] NFSD: move filehandle format declarations out of "uapi".
Date: Thu, 02 Sep 2021 11:14:47 +1000 [thread overview]
Message-ID: <163054528774.24419.6639477440713170169@noble.neil.brown.name> (raw)
In-Reply-To: <F517668C-DD79-4358-96AE-1566B956025A@oracle.com>
A small part of the declaration concerning filehandle format are
currently in the "uapi" include directory:
include/uapi/linux/nfsd/nfsfh.h
There is a lot more to the filehandle format, including "enum fid_type"
and "enum nfsd_fsid" which are not exported via "uapi".
This small part of the filehandle definition is of minimal use outside
of the kernel, and I can find no evidence that an other code is using
it. Certainly nfs-utils and wireshark (The most likely candidates) do not
use these declarations.
So move it out of "uapi" by copying the content from
include/uapi/linux/nfsd/nfsfh.h
into
fs/nfsd/nfsfh.h
A few unnecessary "#include" directives are not copied, and neither is
the #define of fh_auth, which is annotated as being for userspace only.
The copyright claims in the uapi file are identical to those in the nfsd
file, so there is no need to copy those.
The "__u32" style integer types are only needed in "uapi". In
kernel-only code we can use the more familiar "u32" style.
Signed-off-by: NeilBrown <neilb@suse.de>
---
fs/nfsd/nfsfh.h | 98 ++++++++++++++++++++++++++-
include/uapi/linux/nfsd/nfsfh.h | 116 --------------------------------
2 files changed, 97 insertions(+), 117 deletions(-)
delete mode 100644 include/uapi/linux/nfsd/nfsfh.h
diff --git a/fs/nfsd/nfsfh.h b/fs/nfsd/nfsfh.h
index 6106697adc04..988e4dfdfbd9 100644
--- a/fs/nfsd/nfsfh.h
+++ b/fs/nfsd/nfsfh.h
@@ -10,9 +10,105 @@
#include <linux/crc32.h>
#include <linux/sunrpc/svc.h>
-#include <uapi/linux/nfsd/nfsfh.h>
#include <linux/iversion.h>
#include <linux/exportfs.h>
+#include <linux/nfs4.h>
+
+
+/*
+ * This is the old "dentry style" Linux NFSv2 file handle.
+ *
+ * The xino and xdev fields are currently used to transport the
+ * ino/dev of the exported inode.
+ */
+struct nfs_fhbase_old {
+ u32 fb_dcookie; /* dentry cookie - always 0xfeebbaca */
+ u32 fb_ino; /* our inode number */
+ u32 fb_dirino; /* dir inode number, 0 for directories */
+ u32 fb_dev; /* our device */
+ u32 fb_xdev;
+ u32 fb_xino;
+ u32 fb_generation;
+};
+
+/*
+ * This is the new flexible, extensible style NFSv2/v3/v4 file handle.
+ * by Neil Brown <neilb@cse.unsw.edu.au> - March 2000
+ *
+ * The file handle starts with a sequence of four-byte words.
+ * The first word contains a version number (1) and three descriptor bytes
+ * that tell how the remaining 3 variable length fields should be handled.
+ * These three bytes are auth_type, fsid_type and fileid_type.
+ *
+ * All four-byte values are in host-byte-order.
+ *
+ * The auth_type field is deprecated and must be set to 0.
+ *
+ * The fsid_type identifies how the filesystem (or export point) is
+ * encoded.
+ * Current values:
+ * 0 - 4 byte device id (ms-2-bytes major, ls-2-bytes minor), 4byte inode number
+ * NOTE: we cannot use the kdev_t device id value, because kdev_t.h
+ * says we mustn't. We must break it up and reassemble.
+ * 1 - 4 byte user specified identifier
+ * 2 - 4 byte major, 4 byte minor, 4 byte inode number - DEPRECATED
+ * 3 - 4 byte device id, encoded for user-space, 4 byte inode number
+ * 4 - 4 byte inode number and 4 byte uuid
+ * 5 - 8 byte uuid
+ * 6 - 16 byte uuid
+ * 7 - 8 byte inode number and 16 byte uuid
+ *
+ * The fileid_type identified how the file within the filesystem is encoded.
+ * The values for this field are filesystem specific, exccept that
+ * filesystems must not use the values '0' or '0xff'. 'See enum fid_type'
+ * in include/linux/exportfs.h for currently registered values.
+ */
+struct nfs_fhbase_new {
+ union {
+ struct {
+ u8 fb_version_aux; /* == 1, even => nfs_fhbase_old */
+ u8 fb_auth_type_aux;
+ u8 fb_fsid_type_aux;
+ u8 fb_fileid_type_aux;
+ u32 fb_auth[1];
+ /* u32 fb_fsid[0]; floating */
+ /* u32 fb_fileid[0]; floating */
+ };
+ struct {
+ u8 fb_version; /* == 1, even => nfs_fhbase_old */
+ u8 fb_auth_type;
+ u8 fb_fsid_type;
+ u8 fb_fileid_type;
+ u32 fb_auth_flex[]; /* flexible-array member */
+ };
+ };
+};
+
+struct knfsd_fh {
+ unsigned int fh_size; /* significant for NFSv3.
+ * Points to the current size while building
+ * a new file handle
+ */
+ union {
+ struct nfs_fhbase_old fh_old;
+ u32 fh_pad[NFS4_FHSIZE/4];
+ struct nfs_fhbase_new fh_new;
+ } fh_base;
+};
+
+#define ofh_dcookie fh_base.fh_old.fb_dcookie
+#define ofh_ino fh_base.fh_old.fb_ino
+#define ofh_dirino fh_base.fh_old.fb_dirino
+#define ofh_dev fh_base.fh_old.fb_dev
+#define ofh_xdev fh_base.fh_old.fb_xdev
+#define ofh_xino fh_base.fh_old.fb_xino
+#define ofh_generation fh_base.fh_old.fb_generation
+
+#define fh_version fh_base.fh_new.fb_version
+#define fh_fsid_type fh_base.fh_new.fb_fsid_type
+#define fh_auth_type fh_base.fh_new.fb_auth_type
+#define fh_fileid_type fh_base.fh_new.fb_fileid_type
+#define fh_fsid fh_base.fh_new.fb_auth_flex
static inline __u32 ino_t_to_u32(ino_t ino)
{
diff --git a/include/uapi/linux/nfsd/nfsfh.h b/include/uapi/linux/nfsd/nfsfh.h
deleted file mode 100644
index 427294dd56a1..000000000000
--- a/include/uapi/linux/nfsd/nfsfh.h
+++ /dev/null
@@ -1,116 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * This file describes the layout of the file handles as passed
- * over the wire.
- *
- * Copyright (C) 1995, 1996, 1997 Olaf Kirch <okir@monad.swb.de>
- */
-
-#ifndef _UAPI_LINUX_NFSD_FH_H
-#define _UAPI_LINUX_NFSD_FH_H
-
-#include <linux/types.h>
-#include <linux/nfs.h>
-#include <linux/nfs2.h>
-#include <linux/nfs3.h>
-#include <linux/nfs4.h>
-
-/*
- * This is the old "dentry style" Linux NFSv2 file handle.
- *
- * The xino and xdev fields are currently used to transport the
- * ino/dev of the exported inode.
- */
-struct nfs_fhbase_old {
- __u32 fb_dcookie; /* dentry cookie - always 0xfeebbaca */
- __u32 fb_ino; /* our inode number */
- __u32 fb_dirino; /* dir inode number, 0 for directories */
- __u32 fb_dev; /* our device */
- __u32 fb_xdev;
- __u32 fb_xino;
- __u32 fb_generation;
-};
-
-/*
- * This is the new flexible, extensible style NFSv2/v3/v4 file handle.
- * by Neil Brown <neilb@cse.unsw.edu.au> - March 2000
- *
- * The file handle starts with a sequence of four-byte words.
- * The first word contains a version number (1) and three descriptor bytes
- * that tell how the remaining 3 variable length fields should be handled.
- * These three bytes are auth_type, fsid_type and fileid_type.
- *
- * All four-byte values are in host-byte-order.
- *
- * The auth_type field is deprecated and must be set to 0.
- *
- * The fsid_type identifies how the filesystem (or export point) is
- * encoded.
- * Current values:
- * 0 - 4 byte device id (ms-2-bytes major, ls-2-bytes minor), 4byte inode number
- * NOTE: we cannot use the kdev_t device id value, because kdev_t.h
- * says we mustn't. We must break it up and reassemble.
- * 1 - 4 byte user specified identifier
- * 2 - 4 byte major, 4 byte minor, 4 byte inode number - DEPRECATED
- * 3 - 4 byte device id, encoded for user-space, 4 byte inode number
- * 4 - 4 byte inode number and 4 byte uuid
- * 5 - 8 byte uuid
- * 6 - 16 byte uuid
- * 7 - 8 byte inode number and 16 byte uuid
- *
- * The fileid_type identified how the file within the filesystem is encoded.
- * The values for this field are filesystem specific, exccept that
- * filesystems must not use the values '0' or '0xff'. 'See enum fid_type'
- * in include/linux/exportfs.h for currently registered values.
- */
-struct nfs_fhbase_new {
- union {
- struct {
- __u8 fb_version_aux; /* == 1, even => nfs_fhbase_old */
- __u8 fb_auth_type_aux;
- __u8 fb_fsid_type_aux;
- __u8 fb_fileid_type_aux;
- __u32 fb_auth[1];
- /* __u32 fb_fsid[0]; floating */
- /* __u32 fb_fileid[0]; floating */
- };
- struct {
- __u8 fb_version; /* == 1, even => nfs_fhbase_old */
- __u8 fb_auth_type;
- __u8 fb_fsid_type;
- __u8 fb_fileid_type;
- __u32 fb_auth_flex[]; /* flexible-array member */
- };
- };
-};
-
-struct knfsd_fh {
- unsigned int fh_size; /* significant for NFSv3.
- * Points to the current size while building
- * a new file handle
- */
- union {
- struct nfs_fhbase_old fh_old;
- __u32 fh_pad[NFS4_FHSIZE/4];
- struct nfs_fhbase_new fh_new;
- } fh_base;
-};
-
-#define ofh_dcookie fh_base.fh_old.fb_dcookie
-#define ofh_ino fh_base.fh_old.fb_ino
-#define ofh_dirino fh_base.fh_old.fb_dirino
-#define ofh_dev fh_base.fh_old.fb_dev
-#define ofh_xdev fh_base.fh_old.fb_xdev
-#define ofh_xino fh_base.fh_old.fb_xino
-#define ofh_generation fh_base.fh_old.fb_generation
-
-#define fh_version fh_base.fh_new.fb_version
-#define fh_fsid_type fh_base.fh_new.fb_fsid_type
-#define fh_auth_type fh_base.fh_new.fb_auth_type
-#define fh_fileid_type fh_base.fh_new.fb_fileid_type
-#define fh_fsid fh_base.fh_new.fb_auth_flex
-
-/* Do not use, provided for userspace compatiblity. */
-#define fh_auth fh_base.fh_new.fb_auth
-
-#endif /* _UAPI_LINUX_NFSD_FH_H */
--
2.32.0
next prev parent reply other threads:[~2021-09-02 1:14 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-26 4:28 [PATCH] NFSD: drop support for ancient file-handles NeilBrown
2021-08-26 6:03 ` [PATCH v2] BTRFS/NFSD: provide more unique inode number for btrfs export NeilBrown
2021-08-26 20:19 ` J. Bruce Fields
2021-08-26 22:10 ` NeilBrown
2021-08-27 14:53 ` Frank Filz
2021-08-27 22:57 ` NeilBrown
2021-08-27 23:46 ` Frank Filz
2021-08-27 23:55 ` NeilBrown
2021-08-28 2:21 ` Frank Filz
2021-08-27 18:32 ` J. Bruce Fields
2021-08-27 23:01 ` NeilBrown
2021-08-27 16:20 ` Christoph Hellwig
2021-08-27 23:05 ` NeilBrown
2021-08-28 7:09 ` Christoph Hellwig
2021-08-31 4:59 ` NeilBrown
2021-09-01 7:20 ` Christoph Hellwig
2021-09-01 15:22 ` J. Bruce Fields
2021-09-02 4:14 ` NeilBrown
2021-09-05 16:07 ` J. Bruce Fields
2021-09-06 1:29 ` NeilBrown
2021-09-11 14:12 ` Amir Goldstein
2021-09-13 0:43 ` NeilBrown
2021-09-13 10:04 ` Amir Goldstein
2021-09-13 22:59 ` NeilBrown
2021-09-14 5:45 ` Amir Goldstein
2021-09-20 22:09 ` NeilBrown
2021-09-02 7:11 ` Christoph Hellwig
2021-09-02 4:06 ` NeilBrown
2021-09-02 7:16 ` Christoph Hellwig
2021-09-02 7:53 ` Miklos Szeredi
2021-09-02 14:16 ` Frank Filz
2021-09-02 23:02 ` NeilBrown
2021-08-26 14:10 ` [PATCH] NFSD: drop support for ancient file-handles Chuck Lever III
2021-08-26 21:38 ` NeilBrown
2021-08-26 14:51 ` J. Bruce Fields
2021-08-26 21:41 ` NeilBrown
2021-08-27 15:15 ` Christoph Hellwig
2021-08-27 23:24 ` NeilBrown
2021-08-31 4:41 ` [PATCH 1/2 v2] NFSD: drop support for ancient filehandles NeilBrown
2021-08-31 4:42 ` [PATCH 2/2] NFSD: simplify struct nfsfh NeilBrown
2021-09-01 7:44 ` Christoph Hellwig
2021-09-01 7:44 ` [PATCH 1/2 v2] NFSD: drop support for ancient filehandles Christoph Hellwig
2021-09-01 14:21 ` Chuck Lever III
2021-09-02 1:14 ` NeilBrown [this message]
2021-09-02 1:15 ` [PATCH 2/3 v3] " NeilBrown
2021-09-02 1:16 ` [PATCH 3/3 v3] NFSD: simplify struct nfsfh NeilBrown
2021-09-02 7:22 ` [PATCH 2/3 v3] NFSD: drop support for ancient filehandles Christoph Hellwig
2021-09-02 7:21 ` [PATCH 1/3 v3] NFSD: move filehandle format declarations out of "uapi" Christoph Hellwig
2021-09-23 21:21 ` Bruce Fields
2021-09-25 4:21 ` NeilBrown
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=163054528774.24419.6639477440713170169@noble.neil.brown.name \
--to=neilb@suse.de \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=hch@lst.de \
--cc=linux-nfs@vger.kernel.org \
/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).