All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Andreas Dilger <adilger@dilger.ca>
Cc: 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,
	Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
Date: Tue, 11 Jun 2019 14:09:07 -0700	[thread overview]
Message-ID: <20190611140907.899bebb12a3d731da24a9ad1@linux-foundation.org> (raw)
In-Reply-To: <6DCAE4F8-3BEC-45F2-A733-F4D15850B7F3@dilger.ca>

On Tue, 11 Jun 2019 15:00:10 -0600 Andreas Dilger <adilger@dilger.ca> wrote:

> >> to FIELD_SIZEOF
> > 
> > As Alexey has pointed out, C structs and unions don't have fields -
> > they have members.  So this is an opportunity to switch everything to
> > a new member_sizeof().
> > 
> > What do people think of that and how does this impact the patch footprint?
> 
> I did a check, and FIELD_SIZEOF() is used about 350x, while sizeof_field()
> is about 30x, and SIZEOF_FIELD() is only about 5x.

Erk.  Sorry, I should have grepped.

> 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.

In that case I'd say let's live with FIELD_SIZEOF() and remove
sizeof_field() and SIZEOF_FIELD().

I'm a bit surprised that the FIELD_SIZEOF() definition ends up in
stddef.h rather than in kernel.h where such things are normally
defined.  Why is that?


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Andreas Dilger <adilger@dilger.ca>
Cc: 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,
	Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
Date: Tue, 11 Jun 2019 21:09:07 +0000	[thread overview]
Message-ID: <20190611140907.899bebb12a3d731da24a9ad1@linux-foundation.org> (raw)
In-Reply-To: <6DCAE4F8-3BEC-45F2-A733-F4D15850B7F3@dilger.ca>

On Tue, 11 Jun 2019 15:00:10 -0600 Andreas Dilger <adilger@dilger.ca> wrote:

> >> to FIELD_SIZEOF
> > 
> > As Alexey has pointed out, C structs and unions don't have fields -
> > they have members.  So this is an opportunity to switch everything to
> > a new member_sizeof().
> > 
> > What do people think of that and how does this impact the patch footprint?
> 
> I did a check, and FIELD_SIZEOF() is used about 350x, while sizeof_field()
> is about 30x, and SIZEOF_FIELD() is only about 5x.

Erk.  Sorry, I should have grepped.

> 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.

In that case I'd say let's live with FIELD_SIZEOF() and remove
sizeof_field() and SIZEOF_FIELD().

I'm a bit surprised that the FIELD_SIZEOF() definition ends up in
stddef.h rather than in kernel.h where such things are normally
defined.  Why is that?

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
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-mips@vger.kernel.org,
	Shyam Saini <shyam.saini@amarulasolutions.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-sctp@vger.kernel.org, dri-devel@lists.freedesktop.org,
	bpf@vger.kernel.org, linux-ext4 <linux-ext4@vger.kernel.org>,
	intel-gvt-dev@lists.freedesktop.org,
	Alexey Dobriyan <adobriyan@gmail.com>,
	linux-arm-kernel@lists.infradead.org, mayhs11saini@gmail.com
Subject: Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
Date: Tue, 11 Jun 2019 14:09:07 -0700	[thread overview]
Message-ID: <20190611140907.899bebb12a3d731da24a9ad1@linux-foundation.org> (raw)
In-Reply-To: <6DCAE4F8-3BEC-45F2-A733-F4D15850B7F3@dilger.ca>

On Tue, 11 Jun 2019 15:00:10 -0600 Andreas Dilger <adilger@dilger.ca> wrote:

> >> to FIELD_SIZEOF
> > 
> > As Alexey has pointed out, C structs and unions don't have fields -
> > they have members.  So this is an opportunity to switch everything to
> > a new member_sizeof().
> > 
> > What do people think of that and how does this impact the patch footprint?
> 
> I did a check, and FIELD_SIZEOF() is used about 350x, while sizeof_field()
> is about 30x, and SIZEOF_FIELD() is only about 5x.

Erk.  Sorry, I should have grepped.

> 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.

In that case I'd say let's live with FIELD_SIZEOF() and remove
sizeof_field() and SIZEOF_FIELD().

I'm a bit surprised that the FIELD_SIZEOF() definition ends up in
stddef.h rather than in kernel.h where such things are normally
defined.  Why is that?


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

  reply	other threads:[~2019-06-11 21:09 UTC|newest]

Thread overview: 45+ 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 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 [this message]
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: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
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-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-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=20190611140907.899bebb12a3d731da24a9ad1@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=adilger@dilger.ca \
    --cc=adobriyan@gmail.com \
    --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.