Module Name: src
Committed By: pgoyette
Date: Sun Sep 9 02:20:17 UTC 2018
Added Files:
src/doc [pgoyette-compat]: TODO.compat-module
Removed Files:
src/doc [pgoyette-compat]: COMPAT-branch-notes
Log Message:
Rename COMPAT-branch-notes to TODO.compat-module
To generate a diff of this commit:
cvs rdiff -u -r1.1.2.24 -r0 src/doc/COMPAT-branch-notes
cvs rdiff -u -r0 -r1.1.2.1 src/doc/TODO.compat-module
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Added files:
Index: src/doc/TODO.compat-module
diff -u /dev/null src/doc/TODO.compat-module:1.1.2.1
--- /dev/null Sun Sep 9 02:20:17 2018
+++ src/doc/TODO.compat-module Sun Sep 9 02:20:17 2018
@@ -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.
+
