124 lines
6.0 KiB
Plaintext
124 lines
6.0 KiB
Plaintext
/* $NetBSD: TODO.compat-module,v 1.5 2019/02/04 22:00:51 mrg Exp $ */
|
|
|
|
DONE
|
|
----
|
|
1. Removed the building of the compat library - it is no longer needed.
|
|
|
|
2. Reverted some intentional auto-load breakage for loading the sysv_ipc
|
|
module; the breakage was introduced as the fix for a build break.
|
|
|
|
3. Split the sysv_ipc compat routines into their own compat_sysv module.
|
|
|
|
4. Resolved some inter-module dependencies.
|
|
|
|
5. Extracted some net/if.c compat routines into the compat module, and
|
|
replaced the originals with indirect (vectored) function calls.
|
|
|
|
6. Reconfirmed existing compat-module dependencies, and update the
|
|
defopt/defflag lines in the config files* as needed, to insure that
|
|
built-in dependencies get resolved.
|
|
|
|
7. Fixed limits on the number of module dependencies and maximum
|
|
recursion level (for auto-loading) have been removed. Previous code
|
|
for reporting module status to userland has been versioned and moved
|
|
to the (new) compat_80 module.
|
|
|
|
8. The old monolithic compat module has been broken into multiple
|
|
modules, one for each old NetBSD version. The monolithic compat
|
|
module is no longer available.
|
|
|
|
Similarly, the compat_sysv and compat_netbsd32 modules have also
|
|
been split into several version-specific modules, and the mini-
|
|
monolithic versions of these modules are no longer provided.
|
|
|
|
9. syscalls.master has been updated to autoload the version-specific
|
|
compat modules rather than the monolithic modules.
|
|
|
|
10. Separated COMPAT_BSDPTY stuff, allowing the COMPAT_60 module to be
|
|
built regardless.
|
|
|
|
11. Implemented a MP-safe mechanism for installing and removing function
|
|
pointers, preventing them from being unloaded (via modunload) while
|
|
in use. Thanks to riastradh@ for the template code.
|
|
|
|
12. Finished splitting the vnd_30 and vnd_50 compat code into separate
|
|
modules.
|
|
|
|
13. Cleaned up some previous vectored routines (related to if_43.c) to
|
|
use the MP-safe mechanism.
|
|
|
|
14. Organized (some of) the netbsd32 machine-dependent code to fit a
|
|
common build framework, and split version-specific code from baseline
|
|
code as needed. More work may be needed here (see #18 below).
|
|
|
|
15. The rtsock.c code has been split into two separate source files,
|
|
one for use in -current and one which is shared with COMPAT_50 (the
|
|
code is shared with -current, but macros are used to define version-
|
|
specific routine names and variable types). Version-specific parts
|
|
of rtsock.c for compat_14 and compat_70 have also been split out and
|
|
included in the relevant version-specific compat modules.
|
|
|
|
TODO - Not required for branch merge
|
|
------------------------------------
|
|
16. Audit the entire code base for any remaining embedded #ifdef's for
|
|
COMPAT_xx. When found, move the actual compat code into the compat
|
|
hierarchy and replace originals with indirect (vectored) calls.
|
|
|
|
17. The compat_60 module still needs some work for XEN systems. We
|
|
probably need some build infrastructure changes to ensure that
|
|
XEN (and, for i386, XEN-PAE) modules are build with the correct
|
|
macros defined and with -I directories specified in the same order
|
|
as for building kernels. See PR port-xen/53130. This currently
|
|
prevents loading of micro-code updates for amd64 processors running
|
|
XEN kernels. This limitation also exists on HEAD.
|
|
|
|
18. There seems to be quite a bit of MD compat_xx code, in the various
|
|
sys/arch/ directories. I haven't yet looked at any of this. But it
|
|
seems to me that the MI compat build infrastructure should have some
|
|
mechanism to "reach over" to the MD code, #include a Makefile.inc file,
|
|
and perhaps define something to enable the MI modcmd code to call a
|
|
compat_xx_MD_init() routine.
|
|
|
|
Note also that there are a few bits of MD code that is COMPAT_44
|
|
related. (The only bit of MI COMPAT_44 code is in the single module
|
|
shared by COMPAT_43 and COMPAT_09.) This affects the cesfic, hp300,
|
|
news68k, and x68k platforms, all in their respective machdep.c
|
|
source file. Additionally, the zaurus platform defines COMPAT_44 in
|
|
its INSTALL kernel configuration - but no other configuration files!
|
|
|
|
As far as I can tell, none of the MD compat code is currently built
|
|
into the monolithic COMPAT module on HEAD. Thus, its absence from
|
|
any of the version-specific modules is not a regression.
|
|
|
|
19. For compat_50, there are some things in dev/gpio and dev/wscons/wsmux
|
|
that I haven't been able to cleanly separate. These items are not
|
|
currently included in the monolithic COMPAT module on HEAD, so lack of
|
|
integration on the branch is not a regression.
|
|
|
|
20. Find all the remaining dependencies on the compat_utils routines and
|
|
deal with them appropriately. For now, we simply ensure that they
|
|
are included in every kernel via 'options COMPAT_UTILS' in file
|
|
sys/conf/std
|
|
|
|
21. The netbsd32_machine32_hook should be moved out of the main kernel
|
|
and into the compat_netbsd32 module. Unfortunately there are some
|
|
machines which include the consumer of this hook but do not have a
|
|
compat_netbsd32 module (specifically, i386 and sgimips). This
|
|
should be sorted out sometime soon, but does not block merging.
|
|
|
|
22. Note that the MPSAFE kernel option is currently not specified for
|
|
building modules, nor is it included in any standard kernel
|
|
configuration files. If you build a custom kernel with the MPSAFE
|
|
option set, and you also use modules (especially those modules for
|
|
network interface device drivers), you'll need to build custom
|
|
modules, too. The MPSAFE stuff needs to be extracted out and made
|
|
into "hooks".
|
|
|
|
23. The raidframe-netbsd32 compat code needs to be better separated
|
|
from the main raidframe module. The current mechanism requires us
|
|
to include compat/netbsd32/netbsd32.h in rf_netbsdkintf.c to get
|
|
various structure definitions. This should all be handled in the
|
|
compat module, but requires that the code in the ioctl switch be
|
|
moved into a function so the compat code can call it directly and
|
|
handle the ioctl commands entirely.
|