All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Dobriyan <adobriyan@gmail.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Shyam Saini <shyam.saini@amarulasolutions.com>,
	kernel-hardening@lists.openwall.com,
	linux-kernel@vger.kernel.org, keescook@chromium.org,
	linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
	intel-gvt-dev@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	netdev@vger.kernel.org, linux-ext4 <linux-ext4@vger.kernel.org>,
	devel@lists.orangefs.org, linux-mm@kvack.org,
	linux-sctp@vger.kernel.org, bpf@vger.kernel.org,
	kvm@vger.kernel.org, mayhs11saini@gmail.com
Subject: Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
Date: Sat, 29 Jun 2019 17:25:10 +0300	[thread overview]
Message-ID: <20190629142510.GA10629@avx2> (raw)
In-Reply-To: <6DCAE4F8-3BEC-45F2-A733-F4D15850B7F3@dilger.ca>

On Tue, Jun 11, 2019 at 03:00:10PM -0600, Andreas Dilger wrote:
> On Jun 11, 2019, at 2:48 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> > On Wed, 12 Jun 2019 01:08:36 +0530 Shyam Saini <shyam.saini@amarulasolutions.com> wrote:

> I did a check, and FIELD_SIZEOF() is used about 350x, while sizeof_field()
> is about 30x, and SIZEOF_FIELD() is only about 5x.
> 
> That said, I'm much more in favour of "sizeof_field()" or "sizeof_member()"
> than FIELD_SIZEOF().  Not only does that better match "offsetof()", with
> which it is closely related, but is also closer to the original "sizeof()".
> 
> Since this is a rather trivial change, it can be split into a number of
> patches to get approval/landing via subsystem maintainers, and there is no
> huge urgency to remove the original macros until the users are gone.  It
> would make sense to remove SIZEOF_FIELD() and sizeof_field() quickly so
> they don't gain more users, and the remaining FIELD_SIZEOF() users can be
> whittled away as the patches come through the maintainer trees.

The signature should be

	sizeof_member(T, m)

it is proper English,
it is lowercase, so is easier to type,
it uses standard term (member, not field),
it blends in with standard "sizeof" operator,

WARNING: multiple messages have this Message-ID (diff)
From: Alexey Dobriyan <adobriyan@gmail.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Shyam Saini <shyam.saini@amarulasolutions.com>,
	kernel-hardening@lists.openwall.com,
	linux-kernel@vger.kernel.org, keescook@chromium.org,
	linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
	intel-gvt-dev@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	netdev@vger.kernel.org, linux-ext4 <linux-ext4@vger.kernel.org>,
	devel@lists.orangefs.org, linux-mm@kvack.org,
	linux-sctp@vger.kernel.org, bpf@vger.kernel.org,
	kvm@vger.kernel.org, mayhs11saini@gmail.com
Subject: Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
Date: Sat, 29 Jun 2019 14:25:10 +0000	[thread overview]
Message-ID: <20190629142510.GA10629@avx2> (raw)
In-Reply-To: <6DCAE4F8-3BEC-45F2-A733-F4D15850B7F3@dilger.ca>

On Tue, Jun 11, 2019 at 03:00:10PM -0600, Andreas Dilger wrote:
> On Jun 11, 2019, at 2:48 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> > On Wed, 12 Jun 2019 01:08:36 +0530 Shyam Saini <shyam.saini@amarulasolutions.com> wrote:

> I did a check, and FIELD_SIZEOF() is used about 350x, while sizeof_field()
> is about 30x, and SIZEOF_FIELD() is only about 5x.
> 
> That said, I'm much more in favour of "sizeof_field()" or "sizeof_member()"
> than FIELD_SIZEOF().  Not only does that better match "offsetof()", with
> which it is closely related, but is also closer to the original "sizeof()".
> 
> Since this is a rather trivial change, it can be split into a number of
> patches to get approval/landing via subsystem maintainers, and there is no
> huge urgency to remove the original macros until the users are gone.  It
> would make sense to remove SIZEOF_FIELD() and sizeof_field() quickly so
> they don't gain more users, and the remaining FIELD_SIZEOF() users can be
> whittled away as the patches come through the maintainer trees.

The signature should be

	sizeof_member(T, m)

it is proper English,
it is lowercase, so is easier to type,
it uses standard term (member, not field),
it blends in with standard "sizeof" operator,

WARNING: multiple messages have this Message-ID (diff)
From: Alexey Dobriyan <adobriyan@gmail.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: keescook@chromium.org, kvm@vger.kernel.org,
	kernel-hardening@lists.openwall.com, netdev@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, devel@lists.orangefs.org,
	linux-kernel@vger.kernel.org,
	Shyam Saini <shyam.saini@amarulasolutions.com>,
	linux-mips@vger.kernel.org, linux-mm@kvack.org,
	linux-sctp@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	intel-gvt-dev@lists.freedesktop.org, bpf@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, mayhs11saini@gmail.com
Subject: Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
Date: Sat, 29 Jun 2019 17:25:10 +0300	[thread overview]
Message-ID: <20190629142510.GA10629@avx2> (raw)
In-Reply-To: <6DCAE4F8-3BEC-45F2-A733-F4D15850B7F3@dilger.ca>

On Tue, Jun 11, 2019 at 03:00:10PM -0600, Andreas Dilger wrote:
> On Jun 11, 2019, at 2:48 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> > On Wed, 12 Jun 2019 01:08:36 +0530 Shyam Saini <shyam.saini@amarulasolutions.com> wrote:

> I did a check, and FIELD_SIZEOF() is used about 350x, while sizeof_field()
> is about 30x, and SIZEOF_FIELD() is only about 5x.
> 
> That said, I'm much more in favour of "sizeof_field()" or "sizeof_member()"
> than FIELD_SIZEOF().  Not only does that better match "offsetof()", with
> which it is closely related, but is also closer to the original "sizeof()".
> 
> Since this is a rather trivial change, it can be split into a number of
> patches to get approval/landing via subsystem maintainers, and there is no
> huge urgency to remove the original macros until the users are gone.  It
> would make sense to remove SIZEOF_FIELD() and sizeof_field() quickly so
> they don't gain more users, and the remaining FIELD_SIZEOF() users can be
> whittled away as the patches come through the maintainer trees.

The signature should be

	sizeof_member(T, m)

it is proper English,
it is lowercase, so is easier to type,
it uses standard term (member, not field),
it blends in with standard "sizeof" operator,

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-06-29 14:25 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-11 19:38 [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro Shyam Saini
2019-06-11 19:50 ` Shyam Saini
2019-06-11 19:38 ` Shyam Saini
2019-06-11 20:46 ` Kees Cook
2019-06-11 20:46   ` Kees Cook
2019-06-11 20:46   ` Kees Cook
2019-06-11 21:05   ` Shyam Saini
2019-06-11 21:17     ` Shyam Saini
2019-06-11 21:05     ` Shyam Saini
2019-06-11 20:48 ` Andrew Morton
2019-06-11 20:48   ` Andrew Morton
2019-06-11 20:48   ` Andrew Morton
2019-06-11 21:00   ` Andreas Dilger
2019-06-11 21:00     ` Andreas Dilger
2019-06-11 21:00     ` Andreas Dilger
2019-06-11 21:09     ` Andrew Morton
2019-06-11 21:09       ` Andrew Morton
2019-06-11 21:09       ` Andrew Morton
2019-06-11 21:27       ` Shyam Saini
2019-06-11 21:39         ` Shyam Saini
2019-06-11 21:27         ` Shyam Saini
2019-06-11 21:28       ` Andreas Dilger
2019-06-11 21:28         ` Andreas Dilger
2019-06-11 21:28         ` Andreas Dilger
2019-06-29 14:25     ` Alexey Dobriyan [this message]
2019-06-29 14:25       ` Alexey Dobriyan
2019-06-29 14:25       ` Alexey Dobriyan
2019-06-29 16:45       ` Joe Perches
2019-06-29 16:45         ` Joe Perches
2019-06-29 16:45         ` Joe Perches
2019-06-29 16:45         ` Joe Perches
2019-07-02 16:33         ` Kees Cook
2019-07-02 16:33           ` Kees Cook
2019-07-02 16:33           ` Kees Cook
2019-07-02 16:33           ` Kees Cook
2019-06-12  0:05 ` Alexei Starovoitov
2019-06-12  0:05   ` Alexei Starovoitov
2019-06-12  0:05   ` Alexei Starovoitov
2019-06-13  0:31 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2019-06-13  2:15 ` ✓ Fi.CI.BAT: success " Patchwork
2019-06-14 14:36 ` ✓ Fi.CI.IGT: " Patchwork

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=20190629142510.GA10629@avx2 \
    --to=adobriyan@gmail.com \
    --cc=adilger@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=bpf@vger.kernel.org \
    --cc=devel@lists.orangefs.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=mayhs11saini@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=shyam.saini@amarulasolutions.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.