Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/pgoyette-compat]: src/doc Update with notes from a recent status update ...
details: https://anonhg.NetBSD.org/src/rev/c07f23f35b71
branches: pgoyette-compat
changeset: 321153:c07f23f35b71
user: pgoyette <pgoyette%NetBSD.org@localhost>
date: Mon Apr 16 09:53:02 2018 +0000
description:
Update with notes from a recent status update e-mail sent to tech-kern
diffstat:
doc/COMPAT-branch-notes | 138 +++++++++++++++++++++++++++++++++--------------
1 files changed, 96 insertions(+), 42 deletions(-)
diffs (160 lines):
diff -r dbf5e3b05ba6 -r c07f23f35b71 doc/COMPAT-branch-notes
--- a/doc/COMPAT-branch-notes Mon Apr 16 03:41:34 2018 +0000
+++ b/doc/COMPAT-branch-notes Mon Apr 16 09:53:02 2018 +0000
@@ -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.
+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.
+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.
+3. Split the sysv_ipc compat routines into their own compat_sysv module.
-4. Resolved some inter-module dependencies.
+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.
+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.
+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.
+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.
+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.
+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.
-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.
+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.)
- 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.
+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.
- 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.
+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.
-3. XXX The compat_60 module still needs some work for XEN systems.
+ (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.)
-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.
+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.
+
+
+
Home |
Main Index |
Thread Index |
Old Index