I'm about to take a first stab at LKMifying some emulations, starting with
one that doesn't require a rethinko on exec_elf32 (ick)--COMPAT_SUNOS.  I've
been throwing the LKM emulation deal around a bit with several people
off-list, and I've figured out the direction I want to take on some things,
but I want a little opinion from people that have a little more knowledge
than I of "preferred" coding style in NetBSD.

First off, locore in several ports (fortunately, not for COMPAT_SUNOS) 
contains blocks of code intended to be used by emulations, that are
referenced only as arrays in <emul>_machdep.c.  If I were to move these
small blocks of code out of locore, and into another file, would it be bad
to put these as "asm"  directives in <emul>_machdep.c, or would something
like <emul>_sigcode.S be preferred?

Okay, then there's the little nitpicks in various parts of the
kernel--particularly syscalls and MD signal handling--where there are
conditionals wrapped in #ifdef COMPAT_<emul>.  For non-syscall code, I have
the choice of making these these code bits also conditional on LKM, or
including them outright without conditional.  I'd probably make them
conditional on LKM so they would be included if LKM support were intended.

For syscalls, I'm a little luckier; I could write new, replacement syscalls
that either wrapper the real things or replace them completely.  Fortunately
here, the syscalls where this emulation dependency exists are primarily in
kern_prot.c, so I could conceivably just make compat_43_sys_XXX() functions
and pull the emulation dependency from the file altogether.  The NetBSD
syscall table could then #ifdef on COMPAT_43 to provide the proper function
call as necessary (though COMPAT_43 could be LKMified as well and just hook
itself into the proper place in the syscall table); if COMPAT_43 is
statically linked in, the functions which are replaced could be #ifndef'd
out of the "non-compat" kernel source.

[...Personally, I'd prefer the kern_prot.c "compat" additions just to be
compiled in on all systems and eliminate part of this fiasco.  But there is 
the mindset focused on code speed; would it really be that big a hit?]

Yes, Virginia, there is a problem here; if I were to include compat testing
code dependent on LKM, we might not have 'struct emul emul_<emul>' defined,
which is used to determine if an emulation is being used by a process.  No
problems; this could fixed by having a 'struct emul *__emul_<emul>' that is
initially NULL and points to the proper emul_<emul> structure if either the
LKM is loaded or the emulation is statically compiled in.  Here's another
coding style question--would this be a "Bad Thing"? 

So, I'm off to start making COMPAT_SUNOS a little more independent, though
it will likely (even as an LKM) require COMPAT_43 in the kernel until such
time that I can LKMify COMPAT_43 as described above.

=====
== Todd Vierling (Personal tv@pobox.com; Business tv@lucent.com)
== So you know what, Mikey?  Go to bed.