From owner-freebsd-hackers Sat Jul 8 16:51:20 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA10337 for hackers-outgoing; Sat, 8 Jul 1995 16:51:20 -0700 Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id QAA10321 ; Sat, 8 Jul 1995 16:51:19 -0700 Received: from muggsy.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA27459; Sat, 8 Jul 95 16:46:55 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA29318; Sat, 8 Jul 1995 19:46:54 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id TAA07134; Sat, 8 Jul 1995 19:47:30 GMT Message-Id: <199507081947.TAA07134@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: "Jordan K. Hubbard" Cc: hackers@freebsd.org Subject: Re: token ring anyone In-Reply-To: Your message of "Sat, 08 Jul 1995 14:20:17 MST." <19318.805238417@time.cdrom.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Sat, 08 Jul 1995 19:47:29 +0000 From: Matt Thomas Sender: hackers-owner@freebsd.org Precedence: bulk > > Instead of writing token ring drivers, I think it would be a far better > > investment to write NDIS3 miniport wrapper code for FreeBSD but I digress. > > Care to elaborate? :-) At the end of this message... > > So in essence, until the pain of not having Token Ring exceeds the pain > > threshold of implementation it's unlikely to be done. > > Indeed, and the pain of not having Token Ring generally diminishes > with each passing day as more and more TR user's accept the inevitable > and bail out to Ethernet. > I'm not saying that Token Ring doesn't have its faithful adherants or > some fairly indisputable strenghs (like actually approaching > reasonable link utilization efficiency or having a spare ~5Mb/sec to > play with) but it's still just not enough to break the ethernet > barrier. So until I see someone actually in possession of an IBM or > Madge TR card *and* the hacking skills to do the rest come forward, > I'll assume that the point is entirely moot. I've had a Proteon 1392 hitting in my hardware pile (anyone have a good method of storing lots of PC cards? I got 3com 3c507, 3c503, original NE2000, Intel EtherExpress, SMC Ultra, 3 DEFPAs (2MMF, one UTP), a DEFEA, a DE434, a SMC EtherPower, a SMC EtherPower 10/100, 2 DE435s, 2 DE500s, a DC21140 eval board, 4 DE450s, a SMC EtherPower Enhanced, a DE436, an AHA1540B, a DE100, an original DEPCA, a DE422, a DE425, 2 DE20x, 3 or 4 DE205s. Those are scattered around my desk in a semi-random pile) but I haven't had the masochistic urge to program it. I have also have an 8bit IBM TR card as well. 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. 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. 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. :-) 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. Of course that still leaves the problem of doing source routing ... Matt Thomas Internet: matt@lkg.dec.com 3am Software Foundry WWW URL: Westford, MA Disclaimer: Digital disavows all knowledge of this message