kern/52193: Not all COMPAT_NETBSD32 code is included (or includable) in module

[paul%whooppee.com@localhost]

>Number:         52193
>Category:       kern
>Synopsis:       Not all COMPAT_NETBSD32 code is included (or includable) in module
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 24 22:35:00 +0000 2017
>Originator:     Paul Goyette
>Release:        NetBSD 7.99.66
>Organization:
+------------------+--------------------------+----------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+------------------+--------------------------+----------------------------+
>Environment:
	
	
System: NetBSD speedy.whooppee.com 7.99.66 NetBSD 7.99.66 (SPEEDY 2017-03-24 21:50:36 UTC) #0: Fri Mar 24 22:50:09 UTC 2017 paul%speedy.whooppee.com@localhost:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
Not all COMPAT_NETBSD32 code is modular.  Some of the code is only available
when the COMPAT_NETBSD32 code is compiled as a "built-in" module.

The most recently introduced example of this is in revision 1.96 of
sys/arch/amd64/amd64/trap.c The code conditionally included here will not
get included in any compat_xxx module.
	
>How-To-Repeat:
See above
	
>Fix:
There are allegedly several/many other examples of COMPAT_NETBSD32 code
which is still conditionally included in kernels but doesn't get into the
module.  An audit of kernel code needs to occur to ensure that such code
is properly modularized.

For this specific example, one change that was suggested (by martin@?) is
to introduce a struct md_emul which may be null, or may contain pointers
to md-specific code.  Then trap.c could call mde_handle_lcall();  the
actual mde_handle_lcall() code would be included in a compat-specific
source file.

There are probably other alternatives.  One could, for example, have a
stub function in trap.c with a global function pointer initialized to
NULL.  The compat_netbsd32 module's initialization code could then replace
the pointer-to-the-stub with a pointer-to-real-handler.

Note that I really don't expect this problem to get fixed (neither this
specific example, nor the larger generic problem);  there seems to be very
little interest in modular code in general.  I am simply filing this PR to
ensure that the issue is documented for future generations of NetBSD users.
:)
	

>Unformatted: