Status of COMPAT_xx changes on [pgoyette-compat] branch

[Paul Goyette <paul%whooppee.com@localhost>]

Christos thought that this might be of interest to a wider group of 
people....


I have two primary goals for the [pgoyette-compat] branch.  First, I
want to ensure that all compat_xx code in the kernel is available in
a module, as well as built-in.  This involves untangling the code
from its #ifdef/#endif spaghetti.  Christos has been helping a lot
with this part.

A second goal is to provide a more granular approach to compat code.
Currently, you either compile what you want into your kernel (with a
default of compat_15 and newer), or you load the monolithic compat-
netbsd module.  I'm working towards providing individual modules for
each compat_xx so you can load and unload modules as needed.  (The
monolithic compat-netbsd module can still be used, as a new "alias"
mechanism has been created to allow one module to appear as multiple
modules.)


I've managed to modularize individual versions' compat_xx code for everything 
between compat_80 all the way back to compat_12.  There are some items still 
left undone:

	* The rtsock compatability code needs to be de-spaghetti'd
	  and made separable into rtsock_70 and rtsock_50 pieces.
	* Once rtsock is separated, compat_14 references to rtsock_50
	  routines needs to be verified.
	* For compat_60, still need to figure out what to do with
	  BSDPTY and tty_ptm
	* 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.)

	* 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.
	* 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.

	* 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.

	* 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 that for the last two items, I'm basing my approach on a statement
that mrg@ made in IRC.  Basically he said that compat_43 is not so much
about maintaining binary compatability;  rather 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.


There's still a lot of work to do.  In addition to all of the items
noted above, I have:

	* The compat_netbsd32 and compat_sysv modules need to be
	  granularized, in a manner similar to compat_netbsd

	* The syscall.master tables (for each emulation) need to be
	  updated to autoload the granular compat_xx modules rather
	  than the monolithic modules (and of course, created file
	  need to be regenerated)

	* It might be desirable to remove the current restriction of
	  "no more than 10" required modules.  (This is not very
	  difficult to do, but it would require versioning the
	  modctl(2) syscall MODCTL_STAT operation, which currently
	  has a fixed-size buffer for each module's information.)
	  The current limit is 10.

Note that this last item, coupled with a restriction on the maximum
recursion depth (previously limited to 6), had created an upper limit
of the number of compat modules (each module needs to "require" the
compat modules for all more-recent versions).  The recursion limit
has now been removed, so there's no longer an upper limit.


Feel free to ping me with any questions.


+------------------+--------------------------+----------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+------------------+--------------------------+----------------------------+