Messages in this thread | | | Date | Wed, 26 Jan 2022 02:43:45 -0800 | From | Lucas De Marchi <> | Subject | Re: [Intel-gfx] [PATCH v2 09/11] drm: Convert open-coded yes/no strings to yesno() |
| |
On Wed, Jan 26, 2022 at 12:12:50PM +0200, Andy Shevchenko wrote: >On Wed, Jan 26, 2022 at 11:39 AM Lucas De Marchi ><lucas.demarchi@intel.com> wrote: >> >> linux/string_helpers.h provides a helper to return "yes"/"no" strings. >> Replace the open coded versions with str_yes_no(). The places were
oops, I replaced yesno() here but forgot to do so in the title
>> identified with the following semantic patch: >> >> @@ >> expression b; >> @@ >> >> - b ? "yes" : "no" >> + str_yes_no(b) >> >> Then the includes were added, so we include-what-we-use, and parenthesis >> adjusted in drivers/gpu/drm/v3d/v3d_debugfs.c. After the conversion we >> still see the same binary sizes: >> >> text data bss dec hex filename >> 51149 3295 212 54656 d580 virtio/virtio-gpu.ko.old >> 51149 3295 212 54656 d580 virtio/virtio-gpu.ko >> 1441491 60340 800 1502631 16eda7 radeon/radeon.ko.old >> 1441491 60340 800 1502631 16eda7 radeon/radeon.ko >> 6125369 328538 34000 6487907 62ff63 amd/amdgpu/amdgpu.ko.old >> 6125369 328538 34000 6487907 62ff63 amd/amdgpu/amdgpu.ko >> 411986 10490 6176 428652 68a6c drm.ko.old >> 411986 10490 6176 428652 68a6c drm.ko >> 98129 1636 264 100029 186bd dp/drm_dp_helper.ko.old >> 98129 1636 264 100029 186bd dp/drm_dp_helper.ko >> 1973432 109640 2352 2085424 1fd230 nouveau/nouveau.ko.old >> 1973432 109640 2352 2085424 1fd230 nouveau/nouveau.ko > >This probably won't change for modules, but if you compile in the >linker may try to optimize it. Would be nice to see the old-new for >`make allyesconfig` or equivalent.
just like it would already do, no? I can try and see what happens, but my feeling is that we won't have any change.
> >... > >> seq_printf(m, "\tDP branch device present: %s\n", >> - branch_device ? "yes" : "no"); >> + str_yes_no(branch_device)); > >Can it be now on one line? Same Q for all similar cases in the entire series.
I saw that question in the previous version. I think those are very subjective is they all go a little bit over 80 chars. Some maintainers may prefer one way or the other.
Here we are reducing just 3 chars so I assumed that is the preferred style here. Also keeping it as is helps with the mass conversion since it's easily repeatable if another iteration is needed.
thanks Lucas De Marchi
| |