Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/pgoyette-compat]: src/doc Rename COMPAT-branch-notes to TODO.compat-module
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.
+
Home |
Main Index |
Thread Index |
Old Index