Re: i386 and the COMPAT_50 option

[Andrew Doran <ad%netbsd.org@localhost>]

On Fri, Jan 23, 2009 at 06:15:32PM +0000, Christos Zoulas wrote:

> 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. ?

Here are some more options to consider:

3. Structure the compat code as a full blown emulation like compat_linux.
   Select it depending on binary type / ELF note. All compat code lives in
   the module.

4. Give up and don't support native compat as a module. It was only 20kB
   last time I looked and is not a security hole (excluding SA), so perhaps
   it is just not worth the hassle. The emulations are easy to make into /
   sustain as modules so this argument does not apply to them.

5. As #4 but don't even bother with release level granularity as the only
   rational excuse for this is to make the kernel build with newer
   architectures.

6. Make native compatibility non-optional. Weeping and gnashing of teeth
   ensues.

Andrew