re: untangling the compat mess

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

Christos Zoulas writes:
> In article <27887.1512591836%splode.eterna.com.au@localhost>,
> matthew green  <mrg%eterna.com.au@localhost> wrote:
> >kernel libraries are supposed to be built as a .o not a .a,
> >for modular/lkm kernels.  did this get lost some where?
> >
> >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.
> 
> As a longer term goal we should try to disentangle all the
> compatibility code from the kernel and have it build only as modules.
> For that we need to improve the module registration/de-registration
> process as well as provide better hooking mechanisms so that the
> compat code can intercept the necessary functions. An example how
> not to do compat code is net/rtsock.c :-)

i'm well aware how tangly the compat code really is :-(  :-)

but please don't remove any ability to build these into the
kernel itself -- modules aren't good enough for basic features
yet, an old known issue no one has really attempted to fix.
hopefully you mean "make it possible to use them only as, with
no broken features" not "only able to be."  (modular code is
great, but doesn't have to be built as modules.)

> Part of the idea is to autogenerate a lot of the compat code that
> is just needed for struct layout and constant translation adjustments.

this would be great, but it's a separate issue and doable
anytime..

thanks.


.mrg.

ps: i'm ignoring legal issues and zfs/dtrace/etc modules,
because that's not really our choice.