This is a modified version of Commodores example SANA driver:
the slip.device. As released, it contained a number of bugs and
misfeatures.
Installation:
------------
- It is best to get the full, original SANA developer package. It
is available on Fish disk number 779. Newer versions may be
available by ftp.
- Summary: Place the file (c)slip.device in DEVS:Networks/ and
(c)slip<unit>.config in ENV(ARC):SANA2/.
Additions:
---------
- Now also header-compressed slip. (See RFC-1144 by Van Jacobson) This
is even compatible with non-comressing slip drivers, as it first
tries to trigger the other side of the connection into using
compression as well, but ceases these attempts if they appear
unsuccessful. In any case, once the other side starts sending
compressed headers, it is turned on in the local-to-remote direction
as well.
Corrected bugs:
--------------
- The AbortIO function erroneously assumed that A3 was the Unit
pointer. Even Commodore's official example in the RKM gets that
wrong (see page 567).
- S2_GETGLOBALSTATS always returned an error, even though it worked.
Well, it got the microseconds of the last online wrong.
- S2_TRACKTYPE had two bugs: it would always think a type that you
requested to track would not yet be tracked, even if it would
get the packet type right, which it didn't. As a result, every
call to S2_TRACKTYPE allocated memory for the statistics, yet
S2_GETTYPESTATS always claimed the type wasn't being tracked.
- S2_GETSTATIONADDRESS should return 2 addresses, the current address,
and the ROM address. It used to give only a 0.0.0.0 "ROM" address in
the wrong location. Now, it considers the address in the config
file the "ROM" address, and the one from S2_CONFIGINTERFACE is
the current address. Initially both are the same (and both are
futher ignored since they are meaningless to slip).
- S2_DEVICEQUERY didn't give all required information, and claimed a
weird size for it.
- Flags set when opening the serial device should be in io->io_SerFlags,
not in the flags argument to OpenDevice().
- Returned read requests from the serial device were sized by their
io_Length instead of io_Actual.
- Serial input could potentially overflow the input buffer.
- The code assumed, by using registered arguments, that the callback
routines would have their arguments in the correct registers. Now
the type of the pointer explicitly declares the calling convention.
- And the worst of all: it attempted this EXTREMELY STUPID TRICK:
#define SLIPBase ((struct SLIPDevice *)__builtin_getreg(14))
This is terrible!!! That people write code like this! How can you be
sure the compiler won't use A6 for a register variable somewhere and
make it unusable in the functions that it calls? In fact, SAS/C 6.2
does something like that, in ReadConfig..., when it first calls an Exec
function and then a DOS function, and in both cases fetches the
required base pointer off A6.
If you want global register variables, use a compiler that supports
them, such as gcc.
Corrected misfeatures:
---------------------
- The device now runs at the same priority as the opener. This helps
preventing starvation of the opener in case of high amounts of
input.
- Uses the serial.device's SERF_EOFMODE mode. This prevents the
slip.device from hogging the CPU at high priority, and even at equal
priority improves efficiency.
Debatable issues:
----------------
- Optionally, serial device reads are only initiated when they are
(already) requested by the caller. This is contrary to the SANA
philosophy, and therefore makes debugging protocol stacks more
difficult. On the other hand, why not use the serial device's buffer to
keep input, instead of dropping it? This also reduces CPU load in case
the device is open but unused for some reason. (As it was, the
slip.device would continually read and decode packets, even if nobody
wanted them.)
|
aminet net>