Date: Sun, 9 Jul 95 20:46:49 MDT From: terry@cs.weber.edu (Terry Lambert) To: matt@lkg.dec.com (Matt Thomas) Cc: jkh@freebsd.org, hackers@freebsd.org Subject: Re: token ring anyone Message-ID: <9507100246.AA25273@cs.weber.edu> In-Reply-To: <199507081947.TAA07134@whydos.lkg.dec.com> from "Matt Thomas" at Jul 8, 95 07:47:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Well, I just got off the plane about 2 hours ago, but I can't let this one scrool by! [ ... he has a bunch of token ring cards ... ] > But since the manufacturers have already spent the time to write > NDIS3 drivers for Win95, it would be more interesting to write > the NDIS3 miniport wrappers for them. It wouldn't as fast or as clean > as a native driver but it might be easier. It would be easier. It also would not be sufficient. The miniport driver is only a card driver. Token ring needs a new LLC (which is what most of the stuff Garret was talking about boils down to). You'd need to write that , card driver or not. > NDIS3 miniport drivers has a relatively small set of functions that they > can call and they are 32-bit PIC code. I've thought of taking one or > two of the miniport drivers for one of the cards that I have and seeing > if I can write the NDIS3 shell that they want. From what I've been able > to tell, the work would be about the same as writing a complex device > driver. If successful, the code could probably be used as basis for > using the Win95 SCSI miniport drivers. The main issue is the miniport driver writer documentation for the for the functions that the driver calls back into the WinNT/Win95 kernel isn't sufficient to write them. It'd be a bit of work. > Novell is taking a similar approach with UnixWare. ODI NLM module can > be "transmogrified" such that they be loaded and used under UnixWare. > There's a bit of difference in opinion on how well that works depending > on whether or not they work in Utah. :-) Novell doesn't "transmogrify" the drivers; they are the same ODI drivers that come with the card -- for the NetWare *server*. That's the magic rub. To be able to run them, you basically have to be able to load an NLM with limited library (kernel routine) usage. Actually, I have quite a healthy start on the project... I have most of the necessary documentation. It's basically all on the internet, it's just not very easy to find. Including the ODI binary format, which is in the latest binutils stuff from GNU. I'm more interested in following up some other projects first, with my machine arriving tomorrow, but I'd be willing to point anyone at the places to get information if they want to take the project up. Effectively, you are providing a "NetWare-type" kernel emulation environment. There's actually no reason you couldn't do the same for NetWare disk drivers as well, if you had a VM86() fallback mode with which to load them off of disk (or SCSI miniport drivers for NT or Win95, for that matter, or SCO or Solaris, since all you need to provide is a kernel-level "ABI", just like running their binaries is a matter of supplying a system level ABI). The ODI stuff in UnixWare is less than desirable compared to the native UNIX (DDI/DKI) drivers *for*Novell*protocols*. This is because the three additional layerings and the use of standard run points for Streams (instead of running it as a kernel thread) cause a pretty serious per-packet latency and the Novell protocols are pretty much request-response or request-[fixed window]-response (packetburst) and so the latency hits a hell of a lot harder than it would with TCP/IP (a sliding window protocol -- two latencies averaged over the entire transaction instead of one per packet or one per N packets). > It should be noted that NDIS3 is really brain-dead in some spots (what > else would you expect from Microsoft?) so performance will be not be > great but at least it'll work. In particular, some call-backs into the windows code are done at interrupt level, effectively single-threading the processer and locking it up while it handles the packet processing. ODI, since it has to be safe for a voluntary context switch (the process threading model in NetWare), is actually much better for the job. This begs the question of how long Novell proprietary interfaces will continue to be supported in the industry... if I could really answer that question accurately, I'd be a rich stock-market player instead of a poor programmer -- but I suspect, not that much longer. > Of course that still leaves the problem of doing source routing ... And LLC. But the LLC code could actually also be used for NetBIOS/SMB for LanMan, so it would have large usage -- it's just a bitch of a state machine. As was noted the last time Token Ring came up, much of the necessary code (minus some critical pieces) exists in the X.25/X.29 stuff that is/was in the source tree. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9507100246.AA25273>