Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: i386 and the COMPAT_50 option

On Sun, Jan 25, 2009 at 03:12:43PM +0000, Andrew Doran wrote:
> > 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.

This is not an option.  A binary can be linked to a library which will
use compat code.  It's different from actual emulations because you
can't e.g. link a linux library with a NetBSD program.

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

Modules as a mean to save kernel size is a red herring anyway.  Compat
code, by definition, only changes when the actual kernel changes its
interfaces, it's not something that can have a life of its own.

Quentin Garnier - -
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgp4RRJibmurD.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index