在 2022年05月13日 04:00, Andrew Morton 写道: > On Thu, 12 May 2022 16:26:37 +0800 liqiong <liqiong@xxxxxxxxxxxx> wrote: > >> "char bdi_unknown_nam[]" string form declares a single variable. >> It is better then "char *bdi_unknown_name" which creates two >> variables. >> >> ... >> >> --- a/mm/backing-dev.c >> +++ b/mm/backing-dev.c >> @@ -20,7 +20,7 @@ struct backing_dev_info noop_backing_dev_info; >> EXPORT_SYMBOL_GPL(noop_backing_dev_info); >> >> static struct class *bdi_class; >> -static const char *bdi_unknown_name = "(unknown)"; >> +static const char bdi_unknown_name[] = "(unknown)"; >> > heh, fun patch. We actually do this quite a lot. > > grep -r "^[a-z].*char \*[a-z].*= \"" . > > is a pathetic pattern which catches a lot of them. > > > However. I expected your patch to shrink the kernel a bit, but it has > the opposite effect: > > hp2:/usr/src/25> size mm/backing-dev.o > text data bss dec hex filename > 21288 9396 3808 34492 86bc mm/backing-dev.o-before > 21300 9428 3808 34536 86e8 mm/backing-dev.o-after > > Even .data became larger. I didn't investigate why. Hi, It seems the patch creates a new section: 0000000000000000 l ___ksymtab_gpl+bdi_dev_name 0000000000000000 __ksymtab_bdi_dev_name 0000000000000f60 l O .rodata 000000000000000a bdi_unknown_name And put "bdi_unknown_name" at .rodata.str1.1: This work was published in "KernelJanitors/Todo". It says: "foo []" is better because it declares a single variable, For variables marked __initdata, the "*foo" form causes only the pointer, not the string itself, to be dropped from the kernel image, which is a bug. Using the "foo[]" form with regular 'ole local variables also makes the assembly shorter. I thought it make sense, so i searched the mm tree by "grep -nHre char.*\*.*=.*\"", and checked all the "char *foo" string form, It seems only this one should be fixed.
