From owner-freebsd-hardware@FreeBSD.ORG Thu Oct 5 12:53:17 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D9F116A40F for ; Thu, 5 Oct 2006 12:53:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 391AD43D5D for ; Thu, 5 Oct 2006 12:53:12 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k95Cr703043407; Thu, 5 Oct 2006 08:53:09 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hardware@freebsd.org Date: Thu, 5 Oct 2006 08:52:58 -0400 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610050852.58943.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Thu, 05 Oct 2006 08:53:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1997/Wed Oct 4 11:20:43 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: "Constantine A. Murenin" Subject: Re: ipw(4) and iwi(4): Intel's Pro Wireless firmware licensing problems X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2006 12:53:17 -0000 On Wednesday 04 October 2006 22:46, Constantine A. Murenin wrote: > Hi, > > My acquaintance with Unix started with FreeBSD, which I used for quite > a while before discovering OpenBSD. I now mostly use OpenBSD, and I > was wondering of how many FreeBSD users are aware about the licensing > restrictions of Intel Pro Wireless family of wireless adapters? > > Why are none of the manual pages of FreeBSD say anything about why > Intel Wireless devices do not work by default? > > http://www.freebsd.org/cgi/man.cgi?query=ipw > http://www.freebsd.org/cgi/man.cgi?query=iwi > > If you are curious as to why things are the way they are, I suggest > that you check the problems that are described in the misc@openbsd.org > mailing list, and contact Intel people and say what you think about > their user-unfriendly policy in regards to Intel Pro Wireless > firmwares, which are REQUIRED to be loaded from the OS before the > device functions, i.e. the OS developers must be allowed to freely > distribute the firmware in order for the devices to work > out-of-the-box. > > For some recent information about Intel being an Open Source Fraud, > see http://marc.theaimsgroup.com/?l=openbsd-misc&m=115960734026283&w=2. Probably because all you have to do is install a port and it works. :) In FreeBSD installing a port isn't too difficult for users to do. However, you might want to ask Theo why he complains about Intel not giving him a license for one binary blob (Intel wireless firmware) but complains about Atheros providing a binary blob that he can distribute. Seems a bit of a contradiction to me. However, you probably won't make any headway with that argument because the other side won't be using reason and logic. I think in practice that the distinction between a HAL and firmware is blurry at best. Both are pre-built software to drive hardware and provide a simplified interface to software (i.e. OS) for managing the hardware. The only difference is which portion of RAM that it lives (some RAM chip on the device or in the RAM of the host computer) and that distinction really isn't all that noteworthy. If it's some argument about HAL's encroaching on space needed by the OS, note that firmware has to be in host RAM as well so it can be uploaded. In fact, for iwi(4) and ipw(4) the drivers keep it around all the time to handle suspend/resume. The implementation detail of HAL vs firmware is really just a reflection of design choices made by the hardware vendor in where to draw the line between actual hardware vs software to provide their public interface to system software. For a software guy to claim that firmware is ok but HALs mostly just serves to display how ignorant said person is of how things work over in hardware land IMHO. At this point I've said way more than I probably should as I have actual work that I need to be getting done. :) -- John Baldwin