renaming FIELD_SIZEOF to sizeof_member (was Re: [GIT PULL] treewide conversion to sizeof_member() for v5.4-rc1)

renaming FIELD_SIZEOF to sizeof_member (was Re: [GIT PULL] treewide conversion to sizeof_member() for v5.4-rc1)

[Kees Cook]

On Thu, Sep 26, 2019 at 01:56:55PM -0700, Kees Cook wrote:
> On Thu, Sep 26, 2019 at 01:06:01PM -0700, Linus Torvalds wrote:
> >  (a) why didn't this use the already existing and well-named macro
> > that nobody really had issues with?
> 
> That was suggested, but other folks wanted the more accurate "member"
> instead of "field" since a treewide change was happening anyway:
> https://www.openwall.com/lists/kernel-hardening/2019/07/02/2
> 
> At the end of the day, I really don't care -- I just want to have _one_
> macro. :)
> 
> >  (b) I see no sign of the networking people having been asked about
> > their preferences.
> 
> Yeah, that's entirely true. Totally my mistake; it seemed like a trivial
> enough change that I didn't want to bother too many people. But let's
> fix that now... Dave, do you have any concerns about this change of
> FIELD_SIZEOF() to sizeof_member() (or if it prevails, sizeof_field())?

David, can you weight in on this? Are you okay with a mass renaming of
FIELD_SIZEOF() to sizeof_member(), as the largest user of the old macro
is in networking?

Thanks!

-- 
Kees Cook

Re: renaming FIELD_SIZEOF to sizeof_member

[David Miller]

From: Kees Cook <keescook@chromium.org>
Date: Wed, 2 Oct 2019 11:19:16 -0700

> On Thu, Sep 26, 2019 at 01:56:55PM -0700, Kees Cook wrote:
>> On Thu, Sep 26, 2019 at 01:06:01PM -0700, Linus Torvalds wrote:
>> >  (a) why didn't this use the already existing and well-named macro
>> > that nobody really had issues with?
>> 
>> That was suggested, but other folks wanted the more accurate "member"
>> instead of "field" since a treewide change was happening anyway:
>> https://www.openwall.com/lists/kernel-hardening/2019/07/02/2
>> 
>> At the end of the day, I really don't care -- I just want to have _one_
>> macro. :)
>> 
>> >  (b) I see no sign of the networking people having been asked about
>> > their preferences.
>> 
>> Yeah, that's entirely true. Totally my mistake; it seemed like a trivial
>> enough change that I didn't want to bother too many people. But let's
>> fix that now... Dave, do you have any concerns about this change of
>> FIELD_SIZEOF() to sizeof_member() (or if it prevails, sizeof_field())?
> 
> David, can you weight in on this? Are you okay with a mass renaming of
> FIELD_SIZEOF() to sizeof_member(), as the largest user of the old macro
> is in networking?

I have no objection to moving to sizeof_member().

Re: renaming FIELD_SIZEOF to sizeof_member

[Kees Cook]

On Wed, Oct 02, 2019 at 01:21:21PM -0700, David Miller wrote:
> From: Kees Cook <keescook@chromium.org>
> Date: Wed, 2 Oct 2019 11:19:16 -0700
> 
> > On Thu, Sep 26, 2019 at 01:56:55PM -0700, Kees Cook wrote:
> >> On Thu, Sep 26, 2019 at 01:06:01PM -0700, Linus Torvalds wrote:
> >> >  (a) why didn't this use the already existing and well-named macro
> >> > that nobody really had issues with?
> >> 
> >> That was suggested, but other folks wanted the more accurate "member"
> >> instead of "field" since a treewide change was happening anyway:
> >> https://www.openwall.com/lists/kernel-hardening/2019/07/02/2
> >> 
> >> At the end of the day, I really don't care -- I just want to have _one_
> >> macro. :)
> >> 
> >> >  (b) I see no sign of the networking people having been asked about
> >> > their preferences.
> >> 
> >> Yeah, that's entirely true. Totally my mistake; it seemed like a trivial
> >> enough change that I didn't want to bother too many people. But let's
> >> fix that now... Dave, do you have any concerns about this change of
> >> FIELD_SIZEOF() to sizeof_member() (or if it prevails, sizeof_field())?
> > 
> > David, can you weight in on this? Are you okay with a mass renaming of
> > FIELD_SIZEOF() to sizeof_member(), as the largest user of the old macro
> > is in networking?
> 
> I have no objection to moving to sizeof_member().

Great; thank you!

Linus, are you still open to taking this series with Dave's buy-in? I'd
really hate to break it up since it's such a mechanical treewide
change. I'm also happy to wait until the next -rc1 window; whatever you
think is best here.

Thanks!

-- 
Kees Cook