Module Name:    src
Committed By:   pgoyette
Date:           Mon Apr 16 09:53:02 UTC 2018

Modified Files:
        src/doc [pgoyette-compat]: COMPAT-branch-notes

Log Message:
Update with notes from a recent status update e-mail sent to tech-kern


To generate a diff of this commit:
cvs rdiff -u -r1.1.2.9 -r1.1.2.10 src/doc/COMPAT-branch-notes

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/doc/COMPAT-branch-notes
diff -u src/doc/COMPAT-branch-notes:1.1.2.9 src/doc/COMPAT-branch-notes:1.1.2.10
--- src/doc/COMPAT-branch-notes:1.1.2.9	Tue Apr  3 08:29:44 2018
+++ src/doc/COMPAT-branch-notes	Mon Apr 16 09:53:02 2018
@@ -1,60 +1,114 @@
 DONE
 ----
-1. Removed linking of the kernel compat object library into all kernels;
-   using the .o library caused some build breakage, and resulted in the
-   bulk of the compat code being included in every kernel, but without
-   any module linkage.  In turn, this caused failure when loading some
-   modules due to symbols already being defined in the kernel.
-
-2. Reverted some intentional 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. Implemented a mechanism for modules to include "aliases", allowing
-   a single module file to declare multiple names.  For example, a
-   single "compat" module could declare compat_80, compat_70, etc, and
-   other modules could depend on specific compat levels rather than on
-   the entirety of compat.
-
-7. 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.
-
-8. 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.
+1.  Removed linking of the kernel compat object library into all kernels;
+    using the .o library caused some build breakage, and resulted in the
+    bulk of the compat code being included in every kernel, but without
+    any module linkage.  In turn, this caused failure when loading some
+    modules due to symbols already being defined in the kernel.
+
+2.  Reverted some intentional 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.  Implemented a mechanism for modules to include "aliases", allowing
+    a single module file to declare multiple names.  For example, a
+    single "compat" module could declare compat_80, compat_70, etc, and
+    other modules could depend on specific compat levels rather than on
+    the entirety of compat.
+
+7.  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.
+
+8.  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.
 
 
 TODO
 ----
-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. Using the alias mechanism, split compat (and perhaps compat_sysv)
-   into multiple version-specific modules.  Note that in addition to
-   updating the module code, this would also require changes to
-   syscalls.master files to change the names of the modules associated
-   with module-provided syscalls.
-
-   Update:  These are being done simultaneously, with compat code being
-   moved directly to a version-specific module.  All of COMPAT_80 and
-   COMPAT_70, most of COMPAT_60, and much of COMPAT_50 are finished.
-   Still need to decide how to handle the COMPAT_BSDPTY stuff.
-
-   COMPAT_40 is also finished, except for some arch/sh3 MD code.  There
-   is also some arch/m68k MD-specific code remaining for COMPAT_50.
-
-3. XXX The compat_60 module still needs some work for XEN systems.
-
-4. Update syscalls.master to point the compat calls at the specific
-   modules rather than the monolithic compat module.  Update the
-   "required" lists of other modules, too.
+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.  Using the alias mechanism, split compat (and perhaps compat_sysv)
+    into multiple version-specific modules.  Note that in addition to
+    updating the module code, this would also require changes to
+    syscalls.master files to change the names of the modules associated
+    with module-provided syscalls.
+
+    Update:  These are being done simultaneously, with compat code being
+    moved directly to a version-specific module.  All of COMPAT_80 and
+    COMPAT_70, most of COMPAT_60, and much of COMPAT_50 are finished.
+    Still need to decide how to handle the COMPAT_BSDPTY stuff.
+
+    COMPAT_40 is also finished, except for some arch/sh3 MD code.  There
+    is also some arch/m68k MD-specific code remaining for COMPAT_50.
+
+3.  XXX The compat_60 module still needs some work for XEN systems.
+
+4.  Update syscalls.master to point the compat calls at the specific
+    modules rather than the monolithic compat module.  Update the
+    "required" lists of other modules, too.
+
+5.  The rtsock compatability code needs to be de-spaghetti'd and made
+    separable into rtsock_70 and rtsock_50 pieces.
+
+6.  Once rtsock is separated, compat_14 references to rtsock_50 routines
+    needs to be verified.
+
+7.  For compat_60, still need to figure out what to do with BSDPTY and
+    tty_ptm
+
+8.  Also for compat_60, need to fix the building of XEN (and, for i386,
+    XEN-PAE) module variants so that the obj-dir symlinks and the -I
+    include order match those present in a kernel build.  See PR/53130
+    (Currently, this affects the compat_60 module and its implementation
+    of microcode updates for AMD processors - i386 and amd64.)
+
+9.  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.
+
+10. In addition to the ttcompat code in compat_60, there is another
+    ttcompat in compat_43.  The 60 code used to simply update the function
+    pointer, but the 43 code uses a rw_lock to protect the pointer update.
+    Additionally, the 43 code specifically checks to ensure that the
+    initial value of the pointer in NULL before updating it, which would
+    prevent the 43 code from working if the 60 code is already loaded.  (I
+    have some XXX comment in my branch code for this.)
+
+    I suspect that the right this to do here is probably to make _two_
+    indirect function calls in the main tty code, use separate pointers
+    for the 60 and 43 compat stuff, and remove the rw_lock stuff.
+
+11. There's a vfs sysctl call that currently is build under COMPAT_09 ||
+    COMPAT_43.  I don't understand enough of unix history to figure out if
+    this really belongs to both compat_xx modules (which would require
+    building a separate module, required by both) or if it belongs to a
+    specific module.
+
+    (This is based on a statement that mrg@ made in IRC, which basically
+    said that compat_43 is not as much about maintaining binary
+    compatability  as it is about maintaining old interfaces.  Thus it
+    does _not_ depend on any of the "newer" compat code.  So, compat_43
+    would be able to be loaded on its own, or in combination with any of
+    the other compat modules.)
+
+12. 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.
+
+
+

Reply via email to