Several questions on the packet driver, revision 1.05:

Questions from RNN to JBVB are marked with Q:.  Answers are marked
with A:.  Continued answers on the same topic are marked with C:.

Q: If each interface is supposed to have its own interrupt, why specify a
   handle?
A: A handle is needed because a) you need to ask for several different packet
   types to effectively use IP, and you may want to manipulate them
   separately, and b) because the Packet Driver needs to be able to tell
   application A (IP) from application B (random TSR).  Under DOS,
   multiple programs can use one interface, but different packet types
   (provided they hack DOS well enough to run at the same time).

C: Right.  I missed the "type" specification.  I'm not exactly sure what the
   type specification should contain.  It seems to be dependent upon the
   interface class.  Is this type specification "clearly obvious to the
   expert" (which I'm not yet)?

A: On DEC-Intel-Xerox ("Blue Book") Ethernet, which is what the whole world of
   TCP/IP is using right now, the "type" is assumed to be the 2-byte
   Ethertype (0x800 for IP, 0x806 for ARP, etc.).  On ProNET-10, it would
   be the 1-byte packet type, on 802.5 it would be at least 2 bytes (SSAP,
   DSAP), and might be considerably longer, for instance to cover all 8
   bytes of a SNAP encapsulation.  That is why we include a length.


Q: In the same vein, why specify access_type if there is only one interface
   per interrupt?
A. The same reason as above.


Q: There is no provision for reporting cause of errors, i.e. jam, shorts,
   etc.  Perhaps get_statistics() should return, as part of the statistics
   structure, long errors[10] and char errnames[20][10], where the last is
   the name of the error.
A: That approach only succeeds if the program making the get_statistics()
   call can use the strings directly.  In the case of our 2.0 TSR kernel,
   or with other TSR (LAN program redirectors, etc.), the names aren't
   used because the numbers just get saved, or stuffed into format
   (different) of our net_stats() call.  Programs that call our kernel are
   hardware-independent, so they wouldn't know to do the get_statistics()
   call.

C: I hadn't intended that these error counts be useful to the program -- merely
   useful for a system jock who's trying to debug his code.

A: I would recommend that any actual debugging of a new hardware driver take
   place when it is linked into a normal DOS program (like PCIP).  Then,
   once it is working right, move it into the Packet Driver TSR.  TSRs are
   awfully hard to debug...

In the function access_type():

Q: What is the range of if_number?

A: if_number is somewhat of an appendix.  Due to other aspects of the design
   (no handle on the send_pkt call), the only reasonable value is 0.

Q: When should access_type return BAD_HANDLE?  When out of handles?

A: access_type() can return BAD_HANDLE when out of handles.

Q: When should access_type return TYPE_INUSE?  When the packet type is in use?

A: TYPE_INUSE is intended for just that situation: someone else has
   already claimed either the type specified or some superset of it.

Q: Why is typelen a parameter?  Isn't it a fixed quantity for each
   interface class?

A: typelen is a parameter to allow for situations (802.2 packet headers is
   the only case I can think of at the moment) where the match length
   varies.  With 802.2 headers, one application might want all packets
   with SSAP 1, and another might want SSAP = 1, DSAP = 2, etc.  In
   conventional Blue-Book Ethernet, typelen is effectively a constant, 2.

Q: What if I don't have enough space to store their type? Return NO_SPACE?

A: NO_SPACE is intended for any kind of resource exhaustion that makes the
   access_type() fail.

In the function terminate():

Q: Sounds like the driver shouldn't terminate until and unless all handles
   have either been released.  What if a call to terminate() has been
   made, and there are other handles in use?  Should the driver terminate
   after the last handle has been released?  Sounds like terminate()
   requires a handle that *hasn't* been released.  If it returns
   CANT_TERMINATE, should it also release the handle?

A: I hadn't throught about terminate() much.  Seems like a good idea to
   release the handle, whether or not the call succeeds.  This would allow
   an application to attempt to free up all memory by closing all its
   handles that way (although if this succeeded, the packet driver would
   need to be re-started before another network program could run).