From owner-freebsd-hackers Sat Mar 24 16: 3:18 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 F210837B719; Sat, 24 Mar 2001 16:03:14 -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 f2P03Ep11236; Sat, 24 Mar 2001 16:03:14 -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 f2P03Dh03713; Sat, 24 Mar 2001 16:03:13 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200103250003.f2P03Dh03713@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mjacob@feral.com Cc: Mike Smith , scanner@jurai.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Intel driver doc's Take 2. In-Reply-To: Date: Sat, 24 Mar 2001 16:03:12 -0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > 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, wi th > > header files that define the register bits etc that are reasonably rela ted > > 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 wa nt > > 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. > > Step 4 is a lose. That will never fly because they don't have the interest > or bandwidth to review. I know. That is why I stressed that it is critical that there is a timeout. If there is no timeout, then you get stuck in the situation that Jonathan Lemon is in with his driver. *getting* the timeout clause is the trick. If somebody can manage that, then we are set. Finding somebody with the right marketing/legal connections who can get this in writing and who is naive enough to think that their internal departments will spend the time is what requires luck and/or persistance. There is no point beginning this process unless you can get the procedure *in writing*. 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