On Sat, Jun 29, 2019 at 09:45:10AM -0700, Joe Perches wrote: > On Sat, 2019-06-29 at 17:25 +0300, Alexey Dobriyan wrote: > > On Tue, Jun 11, 2019 at 03:00:10PM -0600, Andreas Dilger wrote: > > > On Jun 11, 2019, at 2:48 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Wed, 12 Jun 2019 01:08:36 +0530 Shyam Saini <shyam.saini@xxxxxxxxxxxxxxxxxxxx> 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, > > yes please. > > Also, a simple script conversion applied > immediately after an rc1 might be easiest > rather than individual patches. This seems reasonable to me. I think the patch steps would be: 1) implement sizeof_member(T, m) as a stand-alone macro 2) do a scripted replacement of all identical macros. 3) remove all the identical macros. Step 2 can be a patch that includes the script used to do the replacement. That way Linus can choose to just run the script instead of taking the patch. -- Kees Cook _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
