philipp@OLIVER.CS.MCGILL.CA (Philip Prindeville) (05/04/88)
Hi. I haven't heard much on pcipdriver lately, so I'm assuming that group sort of disappeared. Oh, well. Anyway, I'm working on an implementation of TCP/IP for OS/2 (to be released into PD later), and I was wondering how to implement the network interface driver. Doing an OS/2 device driver seems reasonable because: * they support multiple threads * character devices operate as if in MS/DOS "raw" mode, that is they support multiple byte transfers * there is a highly accessible timer feature available to device drivers for doing reasonable resolution timeouts * and with a bit of cleverness, one could support packet type demultiplexing (when one does an IOCTL to select specific packet types, the process ID is available to the device driver, or -- one can attach device "monitors" that filter out only the desired packet types, though this incurs more overhead) On the otherhand, a network interface program can have modules that are "resident", entry points that are accessible via dynalinks, and can manage H/W interrupts and the I/O space (or some portion of it). Under this scheme, one could have a generalized packet driver specification, say like FTP's (though stack-based, not register based, because the way one calls across protection rings). The reason I'm particulary interested is that I would like this standard to be accepted by industry, so that vendors code can be portable across various interfaces (whether media similar or dissimilar). I'm not anxious to see another scenario like the archetypical content for the IF between Netware and PC/IP, or whatever... So, I'm anxious to hear any ideas in favour of either scheme, including a proposal for an OS/2 generic packet driver (which could conceivably be threaded, instead of using upcalls, which interfere with protection rings). Any bites? -Philip