Date: Tue, 14 Nov 1995 23:39:02 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Cc: terry@lambert.org, davidg@root.com, hsu@cs.hut.fi, current@FreeBSD.org Subject: Re: ISP state their FreeBSD concerns Message-ID: <199511150639.XAA00411@phaeton.artisoft.com> In-Reply-To: <199511150605.WAA19028@freefall.freebsd.org> from "Justin T. Gibbs" at Nov 14, 95 10:05:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >On the contrary. If I were a competitor, I'd have their code torn apart > >withing one week of each new release. > > > >The code is useless without an AIC 7770, which you can only buy from > >Adaptec. > > This just isn't true. You act like you've read the code (in FreeBSD), know > how it works, what it does and its scope, but the more you say, the more > obvious it becomes that none of the above is true. > > To get the information that I'm talking about out of Adaptec's drivers, > you would have to write a disassebler for aic7xxx code, figure > out what portion of the driver is the sequecner code, then disasemble > the x86 kernel code, then figure out what portion of the x86 code > is the HIM (Hardware Interface Module), then understand the HIM, the > sequencer code, the aic7xxx and how they interract. This would tell you > exactly how Adaptec responds to all SCSI phases, messages, and errors > including all of their work arounds. The end result is hardware > independant data that gives Adaptec a competitive edge. Extracting the > information from a binary is much harder than looking through a well > documented piece of source code. OK. I viewed the sequencer code as the most important thing, which you could write a disassembler for with documentation that's publically available. For the SCO HIM based code, V Communications "Sourcer" product will work to pull the code to (semi-documented) assembly code and identify the HIM code. I admit that I hadn't considered that some of the workarounds would be in the HIM, since it seemed "obviously silly", but that's probably an omission on my part. Either way you cut it, even if it takes me 4 weeks, it's a hell of a lot cheaper than going out and doing the work Adaptec did to get the same information. The only thing they've accomplished is increased the inconvenience factor. I still maintain that the inconvenience would be less than the reward, so they really haven't done anything in terms of making it less attractive to rip their stuff off if I'm serious about throwing money at the problem (and less money than I'd have to throw at a "ground-up" verion of my own -- the savings in disk hardware alone would be worth a lot). > >The 1742 argument of "we don't want people building rip-offs of our > >boards and leveraging drivers for our cards to sell their cards instead" > >only holds water if you can legally use the download code without > >violating copyright in a competitors card. > > They don't need to use Adaptec's code. They can use the information in any > design they want. Again is *hardware independant* information. No... what I meant was that people will find it much harder to clone Adaptec's controllers when they own the sequencer and the driver expects to download to it. The 1742 was cloned because it had a fairly well abstracted interface, and all you had to do (as a controller manufacturer) is pretend you were a 1742 (or 1542) and you were in. You didn't have to spend money developing drivers for your board for most popular commercial OS's because they all came with Adaptec drivers, and those drivers worked with your card. It's much harder, just by having the download interface in all the OS's, to clone a 7770 based card, and even then, you have to imitate a patented chipset. So they have protection by device patent, which is a hell of a lot stronger than trying to assert an interface patent. Effectively, they've got proprietary hardware and proprietary boot code and they are worrying about the boot code. > >This has more to do with publication terms and support of developers > >asking questions than it has to do with them actually having anything > >of proprietary value that can't be gotten legally or illegally without > >non-disclosure. > > What does it have to do with "publication terms"? As I've said in the > past they give you all the information you need to program the cards > except for their implementation. They're not hiding anything about > there hardware. They ship firmware on the floppies with the controllers, but you can't use it without the HIM. They are hiding the HIM -- the boot code. Though you may be right that they are attempting to hide the hardware specific knowledge in the HIM itself. Without looking at their code, I can't say for sure. 8-(. > >The "barrier" to competitors is a small one -- much smaller than the > >investment of the time to decypher their download code. > > I think it would take you a couple man months to fully decifer the > HIM and sequencer code. Either is little good without the other for > the type of information I'm talking about since the API they communicate > with is defined by the downloaded code, not the hardware. I think you could do better than that. If you are a competitor who manufactures SCSI controllers, you have engineers on staff who would have a lot of inside knowledge already. And if you threw five of them at it, you could have it apart pretty quickly. The point is that it isn't "protection", it's "nuisance factor". > >It's the download interface itself which is proprietary -- I don't know > > The download interface is "rep outsb" and is not proprietary at all. > The code you download is. But you get a license for it when you buy the controller. But you can't use it with BSD, even though you have a perfectly legal copy on your SCO or UnixWare drivers disk. > >about you, but all the AIC7770 based boards I've seen come with Xenix > >drivers with the sequencer code download image. > > If you really think that its that easy, I'd love to get the information > from you. Let me know when you have Adaptec's HIM and their sequencer code > all worked out. Well, I'm not in the business of doing SCSI controllers, so I don't really feel it's worth the effort to throw the money (time) at the problem. Getting WINE working is the same class of problem. A group that was deadly serious about something like that would divide into two groups, have one group disassemble all of Windows and document it, and the other group would code based on the documentation. It's not an insoluable problem (after all, Insignia solved it, and so did Sun). Which I guess exactly illustrates the point that it's a barrier for the free UNIX community, but not a barrier a competitor that's going to have to spend money on the problem one way or another. I think "nuisance factor" went out of style in software protection schemes when people quit "laser-lock"ing their floppies. 8-). Terry Lambert terry@lambert.org --- 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?199511150639.XAA00411>