Le 05/03/2018 à 11:43, Paul Goyette a écrit :
(Unicast, but feel free to share.)
I wonder if, for now, it would make sense just to add compat_mod.c to the
libcompat.o object? That would "register" the included code, and other
modules which already depend on the compat module (such as the
compat_netbsd32 module) would not try to load another copy.
When are you planning on moving forward with your proposed changes? Seems
like it's time for that next step. :)
I'm already doing way too many things, and I'm not going to start working on
this. But feel free to take my patches and adapt/commit them.
Basically the final goal is:
- Have the common compat code, mostly located in compat/common, depend on
an independent option, like COMPAT_NETBSD or COMPAT_LIB (let's say the
latter). Something that can be put in, or removed from, GENERIC. This
common compat code should only provide functions that are used by _other_
compat modules. These other modules use the functions and may register
them
in the syscall array for example, but the common compat code _does not_
register its functions. It only provides them.
- Modify the "compat.kmod" module to build only the aforementioned common
compat code, and while here rename it to "compat_lib.kmod" (or something
else) for clarity.
- Modify the numerous COMPAT_ options to depend on COMPAT_LIB. The result
is,
if you enable only COMPAT_LINUX for example, then COMPAT_LIB gets enabled
as a dependency, and will compile the common functions.
- Modify the "compat_*.kmod" modules to dynamically depend on
"compat_lib.kmod". In such a way that when you modload
"compat_linux.kmod",
if the "compat_lib" dependency is not in the kernel (either because the
kernel was not compiled with COMPAT_LIB or because compat_lib.kmod was not
loaded beforehand), then "compat_lib.kmod" is loaded automatically.
At the end the mess is untangled, and we can think about externalizing all of
our compat options into kernel modules.
Maxime
!DSPAM:5a9d258a255326917519591!