linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Namjae Jeon" <namjae.jeon@samsung.com>
To: "'Matthew Wilcox'" <willy@infradead.org>
Cc: <linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-cifs@vger.kernel.org>,
	<linux-cifsd-devel@lists.sourceforge.net>, <smfrench@gmail.com>,
	<senozhatsky@chromium.org>, <hyc.lee@gmail.com>,
	<viro@zeniv.linux.org.uk>, <hch@lst.de>, <hch@infradead.org>,
	<ronniesahlberg@gmail.com>, <aurelien.aptel@gmail.com>,
	<aaptel@suse.com>, <sandeen@sandeen.net>,
	<dan.carpenter@oracle.com>, <colin.king@canonical.com>,
	<rdunlap@infradead.org>,
	"'Sergey Senozhatsky'" <sergey.senozhatsky@gmail.com>,
	"'Steve French'" <stfrench@microsoft.com>
Subject: RE: [PATCH 1/5] cifsd: add server handler and tranport layers
Date: Tue, 23 Mar 2021 12:01:22 +0900	[thread overview]
Message-ID: <00d901d71f90$cdfd24f0$69f76ed0$@samsung.com> (raw)
In-Reply-To: <20210322221816.GW1719932@casper.infradead.org>

> On Mon, Mar 22, 2021 at 02:13:40PM +0900, Namjae Jeon wrote:
> > +#define RESPONSE_BUF(w)		((void *)(w)->response_buf)
> > +#define REQUEST_BUF(w)		((void *)(w)->request_buf)
> 
> Why do you do this obfuscation?
I don't remember exactly, but back then, It looked easier...
> 
> > +#define RESPONSE_BUF_NEXT(w)	\
> > +	((void *)((w)->response_buf + (w)->next_smb2_rsp_hdr_off))
> > +#define REQUEST_BUF_NEXT(w)	\
> > +	((void *)((w)->request_buf + (w)->next_smb2_rcv_hdr_off))
> 
> These obfuscations aren't even used; delete them
They are used in many place.
./smb2pdu.c:            *rsp = RESPONSE_BUF_NEXT(work);
./smb2pdu.c:            err_rsp = RESPONSE_BUF_NEXT(work);
./smb2pdu.c:            rsp_hdr = RESPONSE_BUF_NEXT(work);
./smb2pdu.c:    struct smb2_hdr *hdr = RESPONSE_BUF_NEXT(work);
./smb2pdu.c:    struct smb2_hdr *rsp = RESPONSE_BUF_NEXT(work);
./smb2pdu.c:    rsp_hdr = RESPONSE_BUF_NEXT(work);
./smb2pdu.c:            rsp = RESPONSE_BUF_NEXT(work);
./smb2pdu.c:            rsp = RESPONSE_BUF_NEXT(work);
./smb2pdu.c:            hdr = RESPONSE_BUF_NEXT(work);
./smb2pdu.c:            hdr = RESPONSE_BUF_NEXT(work);
./smb2pdu.c:            rsp = RESPONSE_BUF_NEXT(work);

./smb2pdu.c:            *req = REQUEST_BUF_NEXT(work);
./smb2pdu.c:            rcv_hdr = REQUEST_BUF_NEXT(work);
./smb2pdu.c:    struct smb2_hdr *req_hdr = REQUEST_BUF_NEXT(work);
./smb2pdu.c:    struct smb2_hdr *req = REQUEST_BUF_NEXT(work);
./smb2pdu.c:    rcv_hdr = REQUEST_BUF_NEXT(work);
./smb2pdu.c:    hdr = REQUEST_BUF_NEXT(work);
./smb2pdu.c:            req = REQUEST_BUF_NEXT(work);
./smb2pdu.c:            req = REQUEST_BUF_NEXT(work);
./smb2pdu.c:            hdr = REQUEST_BUF_NEXT(work);
./smb2pdu.c:    req_hdr = REQUEST_BUF_NEXT(work);
./smb2pdu.c:            hdr = REQUEST_BUF_NEXT(work);
./smb2pdu.c:    req_hdr = REQUEST_BUF_NEXT(work);
> 
> > +#define RESPONSE_SZ(w)		((w)->response_sz)
> > +
> > +#define INIT_AUX_PAYLOAD(w)	((w)->aux_payload_buf = NULL)
> > +#define HAS_AUX_PAYLOAD(w)	((w)->aux_payload_sz != 0)
> 
> I mean, do you really find it clearer to write:
> 
> 	if (HAS_AUX_PAYLOAD(work))
> than
> 	if (work->aux_payload_sz)
> 
> The unobfuscated version is actually shorter!
Yep, looks better, Will fix it.

Thanks for your review!



  reply	other threads:[~2021-03-23  3:02 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210322052203epcas1p21fe2d04c4df5396c466c38f4d57d8bb8@epcas1p2.samsung.com>
2021-03-22  5:13 ` [PATCH 0/5] cifsd: introduce new SMB3 kernel server Namjae Jeon
     [not found]   ` <CGME20210322052204epcas1p1382cadbfe958d156c0ad9f7fcb8532b7@epcas1p1.samsung.com>
2021-03-22  5:13     ` [PATCH 1/5] cifsd: add server handler and tranport layers Namjae Jeon
2021-03-22 22:18       ` Matthew Wilcox
2021-03-23  3:01         ` Namjae Jeon [this message]
2021-03-23  3:12           ` Matthew Wilcox
2021-03-23  3:16             ` Namjae Jeon
     [not found]   ` <CGME20210322052206epcas1p438f15851216f07540537c5547a0a2c02@epcas1p4.samsung.com>
2021-03-22  5:13     ` [PATCH 2/5] cifsd: add server-side procedures for SMB3 Namjae Jeon
2021-03-22  6:47       ` Dan Carpenter
2021-03-22  6:50         ` Christoph Hellwig
2021-03-22 13:25           ` [Linux-cifsd-devel] " Stefan Metzmacher
2021-03-22 23:20           ` Namjae Jeon
2021-03-22 23:17         ` Namjae Jeon
2021-03-23  7:19           ` Dan Carpenter
2021-03-25  5:25             ` Sebastian Gottschall
2021-03-22  8:34       ` Matthew Wilcox
2021-03-22 10:27         ` Sergey Senozhatsky
2021-03-22 13:12           ` Matthew Wilcox
     [not found]   ` <CGME20210322052207epcas1p3f0a5bdfd2c994a849a67b465479d0721@epcas1p3.samsung.com>
2021-03-22  5:13     ` [PATCH 3/5] cifsd: add file operations Namjae Jeon
2021-03-22  6:55       ` Al Viro
2021-03-23  0:12         ` Namjae Jeon
2021-03-22  7:02       ` Al Viro
2021-03-22  9:26         ` Sergey Senozhatsky
2021-03-22  7:04       ` Dan Carpenter
2021-03-22  9:39         ` Sergey Senozhatsky
2021-03-22  8:15       ` Matthew Wilcox
2021-03-22  9:03         ` Sergey Senozhatsky
2021-03-22 13:02           ` Matthew Wilcox
2021-03-22 13:57           ` Christoph Hellwig
2021-03-22 14:40             ` Matthew Wilcox
2021-03-22 17:09           ` Matthew Wilcox
2021-03-23  0:05             ` Sergey Senozhatsky
2021-03-22 16:16       ` Schaufler, Casey
2021-03-23  0:21         ` Namjae Jeon
     [not found]   ` <CGME20210322052208epcas1p430b2e93761d5194844c533c61d43242d@epcas1p4.samsung.com>
2021-03-22  5:13     ` [PATCH 4/5] cifsd: add Kconfig and Makefile Namjae Jeon
     [not found]   ` <CGME20210322052209epcas1p377f1542bcc9ec50219d2e57aa92d944b@epcas1p3.samsung.com>
2021-03-22  5:13     ` [PATCH 5/5] MAINTAINERS: add cifsd kernel server Namjae Jeon

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='00d901d71f90$cdfd24f0$69f76ed0$@samsung.com' \
    --to=namjae.jeon@samsung.com \
    --cc=aaptel@suse.com \
    --cc=aurelien.aptel@gmail.com \
    --cc=colin.king@canonical.com \
    --cc=dan.carpenter@oracle.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=hyc.lee@gmail.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-cifsd-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=ronniesahlberg@gmail.com \
    --cc=sandeen@sandeen.net \
    --cc=senozhatsky@chromium.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=smfrench@gmail.com \
    --cc=stfrench@microsoft.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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).