| Message ID | 160527977531.6186.18215866313473241680.stgit@klimt.1015granger.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Update NFSD XDR functions | expand |
> +static __be32 > +nfsd4_decode_access(struct nfsd4_compoundargs *argp, struct nfsd4_access *access) Please fix up a bunch of overly long lines here and in the other patches.
> On Nov 14, 2020, at 4:28 AM, Christoph Hellwig <hch@infradead.org> wrote: > >> +static __be32 >> +nfsd4_decode_access(struct nfsd4_compoundargs *argp, struct nfsd4_access *access) > > Please fix up a bunch of overly long lines here and in the other > patches. Not saying no, but... Kernel coding style and scripts/checkpatch.pl were recently updated to permit 100 character long lines. What reason is there to shorten these? -- Chuck Lever
On Sat, Nov 14, 2020 at 01:26:43PM -0500, Chuck Lever wrote: > > > > On Nov 14, 2020, at 4:28 AM, Christoph Hellwig <hch@infradead.org> wrote: > > > >> +static __be32 > >> +nfsd4_decode_access(struct nfsd4_compoundargs *argp, struct nfsd4_access *access) > > > > Please fix up a bunch of overly long lines here and in the other > > patches. > > Not saying no, but... > > Kernel coding style and scripts/checkpatch.pl were recently > updated to permit 100 character long lines. What reason is > there to shorten these? The coding style only allows it as an exception if it significantly improves readabily. and modern checkpatch.pl unfortunately is wrong more often than not.
> On Nov 14, 2020, at 1:45 PM, Christoph Hellwig <hch@infradead.org> wrote: > > On Sat, Nov 14, 2020 at 01:26:43PM -0500, Chuck Lever wrote: >> >> >>> On Nov 14, 2020, at 4:28 AM, Christoph Hellwig <hch@infradead.org> wrote: >>> >>>> +static __be32 >>>> +nfsd4_decode_access(struct nfsd4_compoundargs *argp, struct nfsd4_access *access) >>> >>> Please fix up a bunch of overly long lines here and in the other >>> patches. >> >> Not saying no, but... >> >> Kernel coding style and scripts/checkpatch.pl were recently >> updated to permit 100 character long lines. What reason is >> there to shorten these? > > The coding style only allows it as an exception if it significantly > improves readabily. and modern checkpatch.pl unfortunately is wrong > more often than not. So you would prefer: static __be32 nfsd4_decode_access(struct nfsd4_compoundargs *argp, struct nfsd4_access *access) ? -- Chuck Lever
On Sat, Nov 14, 2020 at 01:48:13PM -0500, Chuck Lever wrote: > So you would prefer: > > static __be32 nfsd4_decode_access(struct nfsd4_compoundargs *argp, > struct nfsd4_access *access) > > ? My personal preference is two tab alignments for the continuation line, but that vs aligning to the opening brace has always been one of two options with people picking one (another thing recent checkpatch.pl gets wrong).
diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c index 26265d649c39..ee9ba5f0faff 100644 --- a/fs/nfsd/nfs4xdr.c +++ b/fs/nfsd/nfs4xdr.c @@ -437,17 +437,6 @@ nfsd4_decode_stateid(struct nfsd4_compoundargs *argp, stateid_t *sid) DECODE_TAIL; } -static __be32 -nfsd4_decode_access(struct nfsd4_compoundargs *argp, struct nfsd4_access *access) -{ - DECODE_HEAD; - - READ_BUF(4); - access->ac_req_access = be32_to_cpup(p++); - - DECODE_TAIL; -} - static __be32 nfsd4_decode_cb_sec(struct nfsd4_compoundargs *argp, struct nfsd4_cb_sec *cbs) { DECODE_HEAD; @@ -529,6 +518,18 @@ static __be32 nfsd4_decode_cb_sec(struct nfsd4_compoundargs *argp, struct nfsd4_ DECODE_TAIL; } +/* + * NFSv4 operation argument decoders + */ + +static __be32 +nfsd4_decode_access(struct nfsd4_compoundargs *argp, struct nfsd4_access *access) +{ + if (xdr_stream_decode_u32(argp->xdr, &access->ac_req_access) < 0) + return nfserr_bad_xdr; + return nfs_ok; +} + static __be32 nfsd4_decode_backchannel_ctl(struct nfsd4_compoundargs *argp, struct nfsd4_backchannel_ctl *bc) { DECODE_HEAD;
Signed-off-by: Chuck Lever <chuck.lever@oracle.com> --- fs/nfsd/nfs4xdr.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-)