Re: i386 and the COMPAT_50 option

[christos%astron.com@localhost (Christos Zoulas)]

In article <200901231755.n0NHtla3004644%lothlorien.nfbcal.org@localhost>,
Brian Buhrow <buhrow%lothlorien.nfbcal.org@localhost> wrote:

>       Hello.  Sorry if this is a dumb question, but doesn't this change sort
>of imply that if I want to change my compatibility options, I now have to
>modify more than just a config file?  I now have to modify Makefiles all
>over the system as well as the config file?  that seems like a step
>backward, or I'm missing something completely obvious.
>-Brian

It is even worse than that... Here's an explanation:

Most compat code has been pushed into a module. Kernels without
compat options, will load the compat module when a system call is
needed. Unfortunately this does not cover all the bases; there are
other compat hooks to functions for example in the routing socket
code (net/rtsock.c) some ioctls, setsockopt, event reading code in
wscons just to name a few. All this kernel compat code is conditionally
compiled with #ifdef COMPAT_XX. So if you go in the pure module
route, you'll lose the compatibility provided by those hooks so
more things might not work. Currently the only way to provide full
compat functionality is to define COMPAT_XX in your kernel. This
is not ideal, because we would really like to push all that code
into modules. Alas it is not as easy. Some solutions are:

        1. Don't provide compatibility.
           + Simplifies code
           - Some programs don't work...
        2. Always compile the hooks in the kernel, not conditionally.
           + Bloat
           - Difficult to separate compat and non-compat code.
        3. Add indirection variables instead of hooks in the kernel
           and auto-load the compat module if the hooks detect that
           it is not.
           + clean
           - complicated
        4. ?

And of course there is always the dependencies between different auto-loaded
modules which make things even more complicated.

christos