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 - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "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