compat code being included in non-compat kernels?

[Paul Goyette <paul%whooppee.com@localhost>]

I've notice an anomaly on which I hope someone can shed some light...

For some time now I've noticed that periodically something triggers the
"load all the exec modules on the off chance that it will let me exec
this image" - the code is function exec_autoload() in kern_exec.c (and
called from execve_loadvm() ).

I haven't found the trigger yet, but that's not the problem about which
I'm currently concerned.

Today's concern is that attempts to load the compat module fail because
all of its symbols are _already_ included in the current kernel, even
though that kernel was compiled with _no_ COMPAT options of any sort!
It seems that everything is in included in the kernel's libcompat.o
which means everything is in the kernel.

Well, almost everything!  The one piece of compat that seems to be
absent is the definition of the module itself, the MODULE(..., compat,
...) which resides in src/sys/compat/common/compat_mod.c

As a result we have a fundamentally broken modularity system where
the compat_netbsd32 cannot be loaded because its required compat cannot
load because its contents are already in the kernel, unregistered!

I'm not sure when this started, but it's been happening for at least
several weeks, and probably a few months.



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