Plans for the future:

01-Dec-88
---------
There is no reason why this is two drivers. It makes things very complicated.
A "Future Major Release" will implement both drivers in one source module,
fully integrated as one driver. You will then:

		SYSGEN> CONNECT TWA0/DRIVER=PYDRIVER
		SYSGEN> CONNECT PYA0/DRIVER=PYDRIVER

This is much neater for a variety of reasons; in particular, a lot of code
in the existing drivers is concerned with switching UCBs and wondering if the
other driver is actually loaded. If there was only one driver, a whole bunch of
code could be eliminated.

	TTDRIVER <-> PYDRIVER (TWAn:)
		     PYDRIVER (PYAn:) <-> User

As the TW device is a port device, there is no QIO interface, therefore the
FDT tables could be used by EXE$QIO and the port vector interface by TTDRIVER.
Much neater. Also, no need to worry about two sets of spinlocks on V5, so much
faster.
We could be really clever, and make PYDRIVER a port and class driver. The port
part would talk to the class part (which just happens to be in the same physical
driver) and the class part could pretend to be a port driver for the benifit of
TTDRIVER. The PYAn: interface would then fit between the two, just filtering out
what was passed between them. This is very neat, but could be a bit over the
top. Hmmmm.

27-Mar-89: First draft of new version done. Will not ship to DECUS this time
	(due to possible chronic instability (in the driver, not me!)).
	Actually, I want to test it with a V5.1 DECwindows interface first.