re: untangling the compat mess

[matthew green <mrg%eterna.com.au@localhost>]

Maxime Villard writes:
> Le 06/12/2017 à 21:23, matthew green a écrit :
> > kernel libraries are supposed to be built as a .o not a .a,
> > for modular/lkm kernels.  did this get lost some where?
> 
> libcompat is a .a, I saw that too

ah, so that is the underlying problem.

> > ie, if you have a MODULAR kernel, then the build should always
> > include all the library stuff, in libkern, etc.  see the
> > KERN_AS variable.
> > 
> > sounds like libcompat is not being treated the same and it
> > should be instead.
> 
> First I thought we could simply switch to (${COMPAT_AS} == "object").
> 
> But then, it means that the compat functions are always compiled in the
> kernel and that there is no option to control that. I believe there needs
> to be an option, and repurposing COMPAT_NETBSD to this end didn't seem
> like a bad idea to me.

there are really only three options here.  one is to fix it to
build as an object so it's always there.  i'm not a huge fan
of this idea, but it's certainly the easy stop-gap solution.
an other is to disentangle the relevant compat options such
that they're either created entirely independantly by compiling
the shared parts into each module.  a third would be to split
the common code into distinct (multiple) modules such that
each consumer only pulls in the parts they need.

i think #3 is the best end-goal as it allows both kernels to
skip the compat they don't need (since any module will have
that via some other module [orstaticically for #2]) while does
not duplicate (compiled) code.


.mrg.