Date: Sun, 16 Apr 95 23:12:13 MDT From: terry@cs.weber.edu (Terry Lambert) To: nc@ain.charm.net (Network Coordinator) Cc: hosokawa@mt.cs.keio.ac.jp, todd@water.eng.mcmaster.ca, questions@FreeBSD.org, hackers@FreeBSD.org Subject: Re: support for Xircom PCMCIA Ethernet adapters? Message-ID: <9504170512.AA06686@cs.weber.edu> In-Reply-To: <Pine.BSF.3.91.950416175405.15001A-100000@ain.charm.net> from "Network Coordinator" at Apr 16, 95 05:56:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> Is there support for the PCMCIA Xircom Creditcard Ethernet Adapter IIPS > > >> in FreeBSD-2.0, or is anyone working on implementing it? Would it be > > >> compatible with any of the supported PCMCIA Ethernet adapters? If anyone > > >> is working on support for it, I'm willing to test. Alternatively, I could > > >> work on this project if I had the proper technical documentation. > > > > I heard Xircom hates free software, and I've not heard that their > > policy had changed. So you won't read any technical documentation as > > long as you want to use it for free software. > > > > Doesn't Linux have a driver supporting some Xircom hardware? I could have > sworn I have seen those running around. Moreover, I still haven't figured > out why companies that make *hardware* hate free software? Its not like > making free software will reduce the purchases or profit margins of their > hardware, in fact, it will probably increase them. [software doesn't make > much sense without hardware]. --How could we run FreeBSD without several > megabytes of RAM? Texas Instruments and/or Micron aren't going to say > their chips aren't designed to be used with free software. Xircom has figured out a rather fast way to talk to ethernets using parallel ports to do the job. The are noticibly unanxious to document this mechanism so that it can be programmed to by their competitors (both allowing the competitor to leverage Xircom marketing efforts by using their drivers ["The card's just like Xircom, only cheaper because we're not amortizing our software costs across an increased hardware cost"] and allowing the competitors access to the interface technology itself by telling them how to do half the work instead of providing undocumented binary code. If the competitor disassembled the code and derived the interface that way, then they would have to amortize the costs of doing so across the cost of *their* equipment, giving them less incentive to do so. So basically it's an anticompetitive practice that happens to not be illegal under either Sherman (Anti Trust) or Rico (Anti Racketeering). There are some absurd technical reasons for doing this for some hardware, but most other hardware falls into the same category. As I suggested in the previous posting, get someone to disassemble and document the interface without you seeing the code, then you write the driver. This is called clean-rooming. Or leverage an existing driver by allowing it to run in your kernel environment. I've suggested a kernel environment emulation for SCO, Novell, and NT drivers (all protected mode, most that come on disks with the hardware that requires them). I believe there is a packet driver for which source is not available. I do not believe there is a Linux driver. 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?9504170512.AA06686>