[src/pgoyette-compat]: src/doc Rename COMPAT-branch-notes to TODO.compat-module

[pgoyette <pgoyette%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/c3b265560f71
branches:  pgoyette-compat
changeset: 830628:c3b265560f71
user:      pgoyette <pgoyette%NetBSD.org@localhost>
date:      Sun Sep 09 02:20:17 2018 +0000

description:
Rename COMPAT-branch-notes to TODO.compat-module

diffstat:

 doc/COMPAT-branch-notes |  103 ------------------------------------------------
 doc/TODO.compat-module  |  103 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 103 insertions(+), 103 deletions(-)

diffs (214 lines):

diff -r de1263bf673f -r c3b265560f71 doc/COMPAT-branch-notes
--- a/doc/COMPAT-branch-notes   Sat Sep 08 23:39:21 2018 +0000
+++ /dev/null   Thu Jan 01 00:00:00 1970 +0000
@@ -1,103 +0,0 @@
-/* $NetBSD: COMPAT-branch-notes,v 1.1.2.24 2018/09/08 23:39:21 pgoyette Exp $ */
-
-DONE
-----
-1.  Returned the build to use a .a compat library rather than a .o
-    library.  The original method used was .a but that was changed
-    (fairly recently) as a work-around to address some support
-    routines that were not being included when needed.  These support
-    modules are now included in their own module, and the work-around
-    is therefore no longer needed.
-
-2.  Reverted some intentional auto-load breakage for loading the sysv_ipc
-    module; the breakage was introduced as the fix for the above-mentioned
-    build breakage.  
-
-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 depedencies and maximum
-    recursion level have been removed.  Previous code for reporting
-    module status to userland has been versioned and moved to the
-    compat_80 module.
-
-8.  The old monolithic compat module has been broken into multiple
-    modules, one for each old NetBSD version.  The monolithic module
-    is still available.
-
-    Similarly, the compat_sysv module has also been split into several
-    version-specific modules, and the mini-monolithic compat_sysv module
-    is still 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.
-
-
-TODO - Required for branch merge
---------------------------------
-none
-
-
-TODO - Not required for branch merge
-------------------------------------
-1.  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.
-
-2.  The rtsock compat code is a disaster, with rtsock_50.c #include-ing
-    the main rtsock.c code with various manipulations of the COMPAT_50
-    macro.  Once rtsock is separated, compat_14 references to rtsock_50
-    routines needs to be verified.
-
-    Currently, this entire code is built for the monolithic COMPAT
-    module, but there's no way to reach the entry points, so none of
-    the compat code can be executed, neither on the branch nor on
-    HEAD.
-
-3.  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.
-
-4.  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.
-
-5.  For compat_50, in addition to rtsock there are some things in dev/vnd,
-    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.
-
-6.  Even though the build mechanism has been switched back to using a
-    .a compat library, it might be useful to make it work with the .o
-    library.
-
diff -r de1263bf673f -r c3b265560f71 doc/TODO.compat-module
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/TODO.compat-module    Sun Sep 09 02:20:17 2018 +0000
@@ -0,0 +1,103 @@
+/* $NetBSD: TODO.compat-module,v 1.1.2.1 2018/09/09 02:20:17 pgoyette Exp $ */
+
+DONE
+----
+1.  Returned the build to use a .a compat library rather than a .o
+    library.  The original method used was .a but that was changed
+    (fairly recently) as a work-around to address some support
+    routines that were not being included when needed.  These support
+    modules are now included in their own module, and the work-around
+    is therefore no longer needed.
+
+2.  Reverted some intentional auto-load breakage for loading the sysv_ipc
+    module; the breakage was introduced as the fix for the above-mentioned
+    build breakage.  
+
+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 depedencies and maximum
+    recursion level have been removed.  Previous code for reporting
+    module status to userland has been versioned and moved to the
+    compat_80 module.
+
+8.  The old monolithic compat module has been broken into multiple
+    modules, one for each old NetBSD version.  The monolithic module
+    is still available.
+
+    Similarly, the compat_sysv module has also been split into several
+    version-specific modules, and the mini-monolithic compat_sysv module
+    is still 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.
+
+
+TODO - Required for branch merge
+--------------------------------
+none
+
+
+TODO - Not required for branch merge
+------------------------------------
+1.  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.
+
+2.  The rtsock compat code is a disaster, with rtsock_50.c #include-ing
+    the main rtsock.c code with various manipulations of the COMPAT_50
+    macro.  Once rtsock is separated, compat_14 references to rtsock_50
+    routines needs to be verified.
+
+    Currently, this entire code is built for the monolithic COMPAT
+    module, but there's no way to reach the entry points, so none of
+    the compat code can be executed, neither on the branch nor on
+    HEAD.
+
+3.  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.
+
+4.  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.
+
+5.  For compat_50, in addition to rtsock there are some things in dev/vnd,
+    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.
+
+6.  Even though the build mechanism has been switched back to using a
+    .a compat library, it might be useful to make it work with the .o
+    library.
+