TODO.compat-module revision 1.1.2.10       1 /* $NetBSD: TODO.compat-module,v 1.1.2.10 2018/09/24 23:23:26 pgoyette Exp $ */
      2 
      3 DONE
      4 ----
      5 1.  Returned the build to use a .a compat library rather than a .o
      6     library.  The original method used was .a but that was changed
      7     (fairly recently) as a work-around to address some support
      8     routines that were not being included when needed.  These support
      9     modules are now included in their own module, and the work-around
     10     is therefore no longer needed.
     11 
     12 2.  Reverted some intentional auto-load breakage for loading the sysv_ipc
     13     module; the breakage was introduced as the fix for the above-mentioned
     14     build breakage.
     15 
     16 3.  Split the sysv_ipc compat routines into their own compat_sysv module.
     17 
     18 4.  Resolved some inter-module dependencies.
     19 
     20 5.  Extracted some net/if.c compat routines into the compat module, and
     21     replaced the originals with indirect (vectored) function calls.
     22 
     23 6.  Reconfirmed existing compat-module dependencies, and update the
     24     defopt/defflag lines in the config files* as needed, to insure that
     25     built-in dependencies get resolved.
     26 
     27 7.  Fixed limits on the number of module depedencies and maximum
     28     recursion level have been removed.  Previous code for reporting
     29     module status to userland has been versioned and moved to the
     30     compat_80 module.
     31 
     32 8.  The old monolithic compat module has been broken into multiple
     33     modules, one for each old NetBSD version.  The monolithic module
     34     is no longer available.
     35 
     36     Similarly, the compat_sysv module has also been split into several
     37     version-specific modules, and the mini-monolithic compat_sysv module
     38     is no longer provided.
     39 
     40 9.  syscalls.master has been updated to autoload the version-specific
     41     compat modules rather than the monolithic modules.
     42 
     43 10. Separated COMPAT_BSDPTY stuff, allowing the COMPAT_60 module to be
     44     built regardless.
     45 
     46 11. Implemented a MP-safe mechanism for installing and removing function
     47     pointers.  Thanks to riastradh@ for the template code.
     48 
     49 12. Replace version-specific parts of the compat_netbsd32 module (and
     50     also the compat_netbsd32_sysv module) with individual modules.  Update
     51     dependencies accordingly.  (Done, but see #13 below.)
     52 
     53 13. Finished splitting the vnd_30 and vnd_50 compat code into separate
     54     modules.
     55 
     56 14. Cleaned up some previous vectored routines (related to if_43.c) to
     57     use the MP-safe mechanism.
     58 
     59 
     60 TODO - Required for branch merge
     61 --------------------------------
     62 15.  Need to finish cleaning up the netbsd32 machine-dependent code, since
     63     the MI code assumes that there's MD file available.
     64 
     65 16. The ieee_80211 compat code needs to be verified to make sure it is
     66     handling the if43_20 compat routine cvtcmd() correctly.
     67 
     68 17. There are a few function pointers in netbsd32 module that need to
     69     be converted to the new MP-safe mechanism.  See files
     70 	netbsd32_mod.c
     71 	netbsd32_module.c
     72 	netbsd32_compat_80.[ch]
     73 	amd64's machdep.c and machdep_16.c
     74 
     75 
     76 TODO - Not required for branch merge
     77 ------------------------------------
     78 18. Audit the entire code base for any remaining embedded #ifdef's for
     79     COMPAT_xx.  When found, move the actual compat code into the compat
     80     hierarchy and replace originals with indirect (vectored) calls.
     81 
     82 19. The rtsock compat code is a disaster, with rtsock_50.c #include-ing
     83     the main rtsock.c code with various manipulations of the COMPAT_50
     84     macro.  Once rtsock is separated, compat_14 references to rtsock_50
     85     routines needs to be verified.
     86 
     87     Currently, this entire code is built for the monolithic COMPAT
     88     module, but there's no way to reach the entry points, so none of
     89     the compat code can be executed, neither on the branch nor on
     90     HEAD.
     91 
     92 20. The compat_60 module still needs some work for XEN systems.  We
     93     probably need some build infrastructure changes to ensure that
     94     XEN (and, for i386, XEN-PAE) modules are build with the correct
     95     macros defined and with -I directories specified in the same order
     96     as for building kernels. See PR port-xen/53130.  This currently
     97     prevents loading of micro-code updates for amd64 processors running
     98     XEN kernels.  This limitation also exists on HEAD.
     99 
    100 21. There seems to be quite a bit of MD compat_xx code, in the various
    101     sys/arch/ directories.  I haven't yet looked at any of this.  But it
    102     seems to me that the MI compat build infrastructure should have some
    103     mechanism to "reach over" to the MD code, #include a Makefile.inc file,
    104     and perhaps define something to enable the MI modcmd code to call a
    105     compat_xx_MD_init() routine.
    106 
    107     Note also that there are a few bits of MD code that is COMPAT_44
    108     related.  (The only bit of MI COMPAT_44 code is in the single module
    109     shared by COMPAT_43 and COMPAT_09.)  This affects the cesfic, hp300,
    110     news68k, and x68k platforms, all in their respective machdep.c
    111     source file.  Additionally, the zaurus platform defines COMPAT_44 in
    112     its INSTALL kernel configuration - but no other configuration files!
    113 
    114     As far as I can tell, none of the MD compat code is currently built
    115     into the monolithic COMPAT module on HEAD.  Thus, its absence from
    116     any of the version-specific modules is not a regression.
    117 
    118 22. For compat_50, in addition to rtsock there are some things in dev/gpio
    119     and dev/wscons/wsmux that I haven't been able to cleanly separate.
    120     These items are not currently included in the monolithic COMPAT module
    121     on HEAD, so lack of integration on the branch is not a regression.
    122 
    123 23. Even though the build mechanism has been switched back to using a
    124     .a compat library, it might be useful to make it work with the .o
    125     library.
    126 
    127 24. We need a mechanism to determine, at run-time, whether or not the
    128     NTP option was selected.  Even though the NTP code is not modular,
    129     other modules (such as clockctl) need to know whether NTP routines
    130     are available.
    131 
    132