Re: mod_devicetable: Make dmi_strmatch.substr const char *

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

On Tue, 19 May 2015 07:46:58 +0100
David Woodhouse <dwmw2@infradead.org> wrote:

> On Mon, 2015-05-18 at 17:07 -0700, Joe Perches wrote:
> > 
> > changed dmi_strmatch.substr from char * to char[79];
> > 
> > Changing it back to const char * would shrink an x86-64
> > defconfig more than 100KB.
> > 
> > $ size vmlinux.old vmlinux.new
> >     text    data     bss      dec    hex filename
> > 11941725 1825624 1085440 14852789 e2a2b5 vmlinux.old
> > 11921172 1730648 1085440 14737260 e0df6c vmlinux.new

What percentage of those are __initdata ?

> > modpost has changed a bit since 2008, is it's time to change it back?
> 
> Does the match table stuff still work if you do that? I thought the
> point in changing to an array was to make the table extraction do the
> right thing because it can't follow pointers...

Can't follow, or can't currently follow. All the data needed appears to
exist.

If you are trying to build a compact kernel with no modules then you can
certainly make them pointers. A more serious and invasive fix would be to
make substr a u32 and replace the text in the match with a Rabin-Karp or
other rolling hash value, then do a rolling hash for the match. As we've
got zlib in the kernel I assume we have the hash to hand ?

The same could be applied to a lot of the other matchers although with
drastically reduced results as they don't have 320 bytes of match
bloating each single entry.

It does however mean something would have to do the substitutions at
compile time, either by writing the rolling hash as a recursive
preprocessor macro or having a tool in the path which is ugly.

Alan