LEICHTER-JERRY@YALE.ARPA.UUCP (06/27/86)
I'm trying to design a network device driver along the lines of
the _NET: device, but this is undocumented in `Guide to writing device
drivers'. Does anyone have a commented driver like this, or documentation
on how to write one? Even an mailbox-like driver would help.
The technique these drivers share is called "UCB cloning" - the user does a
$ASSIGN to unit 0; a new device is created - "cloned" from the unit 0 UCB and
linked into the driver database - and that, rather than unit 0, is assigned to
the user. When the last channel to the UDB is deassigned, it is (usually)
removed from the device database and discarded. (The mailbox driver, mainly
for historical reasons, operates a little differently.) This mechanism is by
no means restricted to network devices; for example, VWS on a VAXStation
creates terminal emulator windows using this technique.
There is no published documentation on this mechanism; you'll have to stare at
driver sources. (It's quite easy to do, though.) One good place to look is
PTYDRIVER (NOT the separate PTDRIVER/PYDRIVER - older versions, at least,
required you to create all the PT's and PY's at startup. Newer ones might use
the cloning mechanism, though.) PTYDRIVER uses the cloning technique to
create pseudoterminals. (Actually, it is "nonstandard" in that every assign
to unit 0 creates TWO devices, one for each "side" of the connection.) (If
you don't have that around, I can send you a copy.)
Also, how is networking divided between netdriver and netacp in Decnet?
Does all IO go thru netacp, or does netdriver talk directly to other
drivers (if so, how?)?.
NETACP is only involved in setting up and tearing down links, and perhaps
some other supervision - it is not invoked for normal I/O. Data passes
between NETDRIVER and the other drivers using internal, undocumented inter-
faces. Again, you would have to look at the sources. Some of the interfaces
are special-case; there is also a newer standard interface called FFI. By
now, it may have replaced all the old special-case code.
Special interfaces like this are done by having alternate entry points into
the drivers. These entry points are called by other drivers, rather than by
the I/O system. Designing and implementing such things can be tricky because
of the synchronization problems involved. There's also the nasty, if funda-
mentally boring, problem of FINDING a driver from within another driver -
drivers are loaded dynamically, and have no fixed addresses. There are
several techniques for doing this, all of them pretty ad hoc - look at the
PTDRIVER/PYDRIVER pair for an example. (PTYDRIVER avoids this problem by
the neat hack of essentially two drivers into a single piece of code. That's
not an option when you need access to existing drivers that you can't change.)
Descriptions of other network implementations (like tcp) would also be
useful. The only one I know anything - not much - about is Wollongong's IP/TCP - which
wouldn't help you much. Their stuff is all ad hoc - as I understand it, they
load a bunch of code into system space and directly grab the interrupts from
the devices they use. VMS mainly doesn't know they are there - but their
drivers can talk to their inserted code.
Eric Gisin, egisin@waterloo.csnet, egisin@waterloo.edu,
egisin@watmath.uucp.
-------