Jon Smirl (email@example.com)
1 Aug 88 23:25:49 GMT
| 1. You do all of your binding (setting up handlers for incoming packets)
| at CONFIG.SYS time, so you can't use many DOS (or OS/2) services while
| starting your protocol modules.
At OS/2 config.sys time a driver can actually do an awful lot *more* than
it can after config.sys time. This is because it is running at ring 3 at
that time and can do file i/o for example. After init, all driver code is
ring 0 and can't do any os services except devhlps. If the above
remark is really about wanting to write protocol code to live at ring
3, this can actually be done within the present structure--see the
response to point 2 below.
Note that we will in the future be extending the protocol manager to add
dynamic binding and unbinding. The current bind command logically can do
that today; all that is missing is the unbind command and a way to ask the
protocol manager to issue a binds and unbinds at run time.
In fact, the version 2 protocol manager spec will allow for several
run time functions, including dynamic binding, unbinding, and query/change
module config settings. Ring 3 APIs to the protocol manager will let
applications invoke these services.
| 2. You cannot un-bind, ever. No transient network protocols built into
| programs, no un-loadable protocol TSRs. Instead, you have to edit a file
| & reboot if you need more memory to run your CAD program or whatever....
See note about our planned bind/unbind extensions above.
Regarding transient protocols--on OS/2 you can do this by writing a stub
protocol module that interfaces to a ring 3 protocol daemon. The daemon
would ioctl threads down to the stub to get requests and pass back
responses--or better, ioctl down the address of a shared memory area where
request queues could be managed between ring 0 and 3. A similar thing
could be done on DOS 3.
Regarding unloading TSRs--again using the stub protocol module, you
could bring in the actual protocol code as an EXE which certainly
could terminate and free its memory.
Regarding "editing a file" to reconfig: there is no requirement for a
module to take its config from protocol.ini, or to do it only at boot
time. Modules can use private means to get config, including doing it
dynamically at run time via ioctls to the driver or whatever. Modules can
be written to even resize themselves when run time reconfig happens--ie, if
they dynamically allocate their buffer space, or have an app-level daemon
do this for them. (All this is saying is that if you are creative you
can even get the effect of dynamic reconfig sooner than when we provide
a standardized way for doing it).
| 3. Rather than telling MAC/Vector what kind of packets you want, instead
| it goes down its list of handlers, asking them one after another "do you
| want this packet". This means that there is no possibility of
| (or even error detection) when two applications want the same type, and
| opens the door for "badly behaved applications" to screw things up for
| the rest of us.
We considered providing a way to provide packet dispatch info to the
vector, but providing adequate flexibility here was far more complexity
and overhead than seemed justified by the need. What does it mean to tell
it "what kind of packet you want"--do you specify what the source address
should be, or destination SAP, or both, or some bit masked address compare,
or do you also want to include specific packet command codes, or protocol
type bytes, or other compare conditions, or what? Cases can be made for all
these and more, and that just leads to absurd complexity for a
little-needed function. In general it is a "configuration error" to have
two drivers installed that would conflict over what packets they want;
indeed, all that a complex descriptor mechanism would do is let you detect
this configuration error. That would be nicer than not detecting it, but
again, the amount of overhead to detect this rather unusual error
condition did not appear justified. The current polling scheme works just
fine for what we believe the 99% case to be--protocols sharing a mac where
the conflicts don't arise. We are interested in any concrete suggestions
on what a better solution would be, or why there is some important need
not addressed by the current solution.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:42:52 GMT