home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD1.mdf / lan / drivrs30 / packetqa.txt < prev    next >
Text File  |  1989-02-20  |  5KB  |  97 lines
  1. Several questions on the packet driver, revision 1.05:
  2.  
  3. Questions from RNN to JBVB are marked with Q:.  Answers are marked
  4. with A:.  Continued answers on the same topic are marked with C:.
  5.  
  6. Q: If each interface is supposed to have its own interrupt, why specify a
  7.    handle?
  8. A: A handle is needed because a) you need to ask for several different packet
  9.    types to effectively use IP, and you may want to manipulate them
  10.    separately, and b) because the Packet Driver needs to be able to tell
  11.    application A (IP) from application B (random TSR).  Under DOS,
  12.    multiple programs can use one interface, but different packet types
  13.    (provided they hack DOS well enough to run at the same time).
  14.  
  15. C: Right.  I missed the "type" specification.  I'm not exactly sure what the
  16.    type specification should contain.  It seems to be dependent upon the
  17.    interface class.  Is this type specification "clearly obvious to the
  18.    expert" (which I'm not yet)?
  19.  
  20. A: On DEC-Intel-Xerox ("Blue Book") Ethernet, which is what the whole world of
  21.    TCP/IP is using right now, the "type" is assumed to be the 2-byte
  22.    Ethertype (0x800 for IP, 0x806 for ARP, etc.).  On ProNET-10, it would
  23.    be the 1-byte packet type, on 802.5 it would be at least 2 bytes (SSAP,
  24.    DSAP), and might be considerably longer, for instance to cover all 8
  25.    bytes of a SNAP encapsulation.  That is why we include a length.
  26.  
  27.  
  28. Q: In the same vein, why specify access_type if there is only one interface
  29.    per interrupt?
  30. A. The same reason as above.
  31.  
  32.  
  33. Q: There is no provision for reporting cause of errors, i.e. jam, shorts,
  34.    etc.  Perhaps get_statistics() should return, as part of the statistics
  35.    structure, long errors[10] and char errnames[20][10], where the last is
  36.    the name of the error.
  37. A: That approach only succeeds if the program making the get_statistics()
  38.    call can use the strings directly.  In the case of our 2.0 TSR kernel,
  39.    or with other TSR (LAN program redirectors, etc.), the names aren't
  40.    used because the numbers just get saved, or stuffed into format
  41.    (different) of our net_stats() call.  Programs that call our kernel are
  42.    hardware-independent, so they wouldn't know to do the get_statistics()
  43.    call.
  44.  
  45. C: I hadn't intended that these error counts be useful to the program -- merely
  46.    useful for a system jock who's trying to debug his code.
  47.  
  48. A: I would recommend that any actual debugging of a new hardware driver take
  49.    place when it is linked into a normal DOS program (like PCIP).  Then,
  50.    once it is working right, move it into the Packet Driver TSR.  TSRs are
  51.    awfully hard to debug...
  52.  
  53. In the function access_type():
  54.  
  55. Q: What is the range of if_number?
  56.  
  57. A: if_number is somewhat of an appendix.  Due to other aspects of the design
  58.    (no handle on the send_pkt call), the only reasonable value is 0.
  59.  
  60. Q: When should access_type return BAD_HANDLE?  When out of handles?
  61.  
  62. A: access_type() can return BAD_HANDLE when out of handles.
  63.  
  64. Q: When should access_type return TYPE_INUSE?  When the packet type is in use?
  65.  
  66. A: TYPE_INUSE is intended for just that situation: someone else has
  67.    already claimed either the type specified or some superset of it.
  68.  
  69. Q: Why is typelen a parameter?  Isn't it a fixed quantity for each
  70.    interface class?
  71.  
  72. A: typelen is a parameter to allow for situations (802.2 packet headers is
  73.    the only case I can think of at the moment) where the match length
  74.    varies.  With 802.2 headers, one application might want all packets
  75.    with SSAP 1, and another might want SSAP = 1, DSAP = 2, etc.  In
  76.    conventional Blue-Book Ethernet, typelen is effectively a constant, 2.
  77.  
  78. Q: What if I don't have enough space to store their type? Return NO_SPACE?
  79.  
  80. A: NO_SPACE is intended for any kind of resource exhaustion that makes the
  81.    access_type() fail.
  82.  
  83. In the function terminate():
  84.  
  85. Q: Sounds like the driver shouldn't terminate until and unless all handles
  86.    have either been released.  What if a call to terminate() has been
  87.    made, and there are other handles in use?  Should the driver terminate
  88.    after the last handle has been released?  Sounds like terminate()
  89.    requires a handle that *hasn't* been released.  If it returns
  90.    CANT_TERMINATE, should it also release the handle?
  91.  
  92. A: I hadn't throught about terminate() much.  Seems like a good idea to
  93.    release the handle, whether or not the call succeeds.  This would allow
  94.    an application to attempt to free up all memory by closing all its
  95.    handles that way (although if this succeeded, the packet driver would
  96.    need to be re-started before another network program could run).
  97.