Date: Sat, 24 Mar 2001 00:05:06 -0800 From: Peter Wemm <peter@netplex.com.au> To: Mike Smith <msmith@FreeBSD.ORG> Cc: scanner@jurai.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Intel driver doc's Take 2. Message-ID: <200103240805.f2O856h92540@mobile.wemm.org> In-Reply-To: <200103222037.f2MKbrs01583@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103240805.f2O856h92540>