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