From owner-freebsd-hackers Sat Mar 24 0: 5:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 25B1437B71B; Sat, 24 Mar 2001 00:05:08 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from mobile.wemm.org (mobile.wemm.org [10.0.0.5]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f2O858p05108; Sat, 24 Mar 2001 00:05:08 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f2O856h92540; Sat, 24 Mar 2001 00:05:06 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200103240805.f2O856h92540@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mike Smith Cc: scanner@jurai.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Intel driver doc's Take 2. In-Reply-To: <200103222037.f2MKbrs01583@mass.dis.org> Date: Sat, 24 Mar 2001 00:05:06 -0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > On Fri, 23 Mar 2001, Daniel C. Sobral wrote: > > > > > Let me just pipe in a bit. Compromise seems just like the kind of thing > > > marketing or legal would want to do. The problem is that _we_ cannot > > > compromise because one cannot write a "half-way there" driver. It's a > > > technical impossibility. > > > > I agree 100%. I don't think this will fly either. I am just making the > > effort to work with Intel to get what we need. It's not going to happen > > overnight. Period. They are not going to change their NDA policy. In the > > future maybe. Actually I will forward the email she sent me this last time > > after I got off the phone with her an hour ago. I mentioned the problems > > Jonathan had with the GigE card. That's why she refers to him. Anyway I > > will forward it in a sec to the list. > > [Speaking here from some experience with this set of issues.] > > The compromise that you want to strike, and really the *only* compromise > that is going to work, is that the *documents* will remain undisclosed, > but information from the documents that is necessary to produce a > functional, high-performance driver may be disclosed, but *only* through > the source code of the driver. > > Thus one or a small group of people sign the NDA, and keep the > documentation. The driver is then developed and maintained by this team, > who also have the opportunity to interact with Intel's engineering > people. The source code resulting from this effort is then released > publically. Intel should probably retain the right to veto code that you > might want to put in the driver if they feel that it risks disclosure > they don't want, but you don't have to suggest this to them unless you > feel you need it as a bargaining chip. > > This would put them in the same situation as they are already in with > their source-available Linux driver; it should not present any more > intellectual property risks than they already face, and as a bonus, it > gets us a better-supported driver. Yes, but for goodness's sake, make sure there are time limits on it! Try this: 1 - Give a select group of people the docs under NDA 2 - If there are any specific features Intel wants avoided, get them to identify them up front. 3 - Let them write a driver that uses whatever features that are useful, with header files that define the register bits etc that are reasonably related to the features used. 4 - Hand over the driver to intel for "final veto" with a pre-agreement in place so that if they do not respond in 30 days we can release it as-is. 5 - If they have specific features or register bit definitions that they want removed, then do so as long as it isn't going to hopelessly cripple the driver. If they want something removed that wasn't covered in the list at the start and is going to cause severe performance problems (say a 10% performance or efficiency drop), too bad. 6 - Repeat the loop for 'final veto' but with a week timeout instead of 30 days. Regarding step 5; if the information is already "out there" (other open source drivers, leaked onto the internet, etc) then it is fair game and we can use it. With somebody like Intel, it is pretty important to get this in some form of writing. They have a horrible habbit of "forgetting" things that are "too hard" (eg: sweeping your driver for unused information). The reason Intel keep a tight lid on this stuff is that they are very afraid of losing their "competitive advantage" of having functional fxp drivers in the Windows installation, while most of the other ethernet cards do not. If somebody can clone the 8255x series such that it is "close enough" from publically available documentation that it will work with the windoze CD drivers, then Intel loses the upper hand. *That* is what they are afraid of. If some taiwanese manufacturer makes a clone and intel goes after them, and they can point to the freebsd fxpreg.h file that thoughtfully defines every single bit and register in the NDA manuals, you can bet that Intel wont be happy. On the other hand, if it meant that they would have had to pull the drivers apart (illegal under DMCA in the US), Intel would be able to sue them to death if they ever tried to sell it in the US. And then there's always the 'trade secrets' lawsuits of death. (remember Intel vs VIA over the "Apollo" BX chipset workalike). The 'yellow manual' describes the chips, steppings, quirks, workarounds, etc in painful detail... In enough detail that one could do a legal 'clean room' implementation if the manual were freely available. However, there are lots of things that would never go into a FreeBSD driver. Things like the microcode interfaces for the wake-on-lan sequencer/filter, etc. There are a bunch of stuff that is totally irrelevant to us. There are a bunch of things on the chips that are so badly broken that they are not useful to us at all (eg: the checksum assistance on the 82559). I'm sure that we could arrange to leave out enough information to make the FreeBSD driver not useful for trying to clean-room a chipset from that would work under windows. On the other hand, maybe Intel do this "just because". Remember what happened with the AMD386 and 486? I bet they never want to take a chance that might happen again. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message