From owner-freebsd-rc@FreeBSD.ORG Sat Nov 12 22:12:11 2005 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FA0816A41F; Sat, 12 Nov 2005 22:12:11 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from mta4.adelphia.net (mta4.adelphia.net [68.168.78.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4CB443D45; Sat, 12 Nov 2005 22:12:10 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [192.168.1.254] (really [70.32.199.60]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051112220825.QKQI3200.mta9.adelphia.net@[192.168.1.254]>; Sat, 12 Nov 2005 17:08:25 -0500 Message-ID: <437667D4.5030205@savvis.net> Date: Sat, 12 Nov 2005 14:08:20 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> <4375246E.3050303@savvis.net> <20051111.165103.110975378.imp@bsdimp.com> <20051112000929.GB10648@odin.ac.hmc.edu> <4375681B.6030808@savvis.net> <20051112175541.GA18302@odin.ac.hmc.edu> In-Reply-To: <20051112175541.GA18302@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org, freebsd-rc@freebsd.org, past@ebs.gr, "M. Warner Losh" Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 22:12:11 -0000 Brooks, [...] >>>>: does anyone have any objections to the /etc/devd.conf patch located at >>>>: >>>>: http://people.freebsd.org/~emax/devd.conf.diff.txt >>>>: >>>>: this patch will add support for a usb bluetooth dongles to devd(8). >>>> >>>>That looks fine to me. >> >>good. thanks for review. i have committed the patch. >> >> >>>>: also while i'm here where do we stick firmware files by default? >>>> >>>>/usr/share seems most logical to me, but suffers from the 'can't load >>>>firmware until after /usr is mounted' issue. For most firmware, this >>>>is a minor issue... >>> >>>It's also not an issue in practice for most installations since /usr is >>>local and gets mounted quite early. It's only when /usr is NFS and not >>>part of / that you usually get into trouble. >> >>let me just some more details. in this particular case i'm interested >>where to put firmware files for bluetooth devices. in particular >> >>1) 3com bluetooth pccard v1 >> >>2) broadcom bcm2033 chip based usb bluetooth devices (belkin, d-link, etc.) >> >>in both cases firmware files are _not_ loadable modules. they are just >>files in vendor specific format. tools are provided (bt3cfw(8) and >>bcmfw(8)) to load firmware into device. >> >>what i would like to do is to add a couple more sections into the >>/etc/devd.conf to handle these devices. those sections can even be >>commented out because we cannot include firmware into the distribution. >>it is up to the user to find firmware and put it in the right place. >> >>so, should i create /usr/share/firmware directory or just use >>/usr/share? is it better to have common place for firmware files or have >>each driver/tool define its own place? > > Instead, I would suggest creating a port that installs the firmware > and a /usr/local/etc/devd/ script simliar to the iwi-firmware port. ok. that sounds fine to me. does anyone have experience with this like this? i mean do i have to contact 3com and broadcom and obtain some sort of permission for this? how does this work? linux bluez has rpm that contains firmware. it seems like they have contacted broadcom, because they have firmware files in their cvs http://cvs.sourceforge.net/viewcvs.py/bluez/firmware/broadcom/ can i legally get those files and include them into freebsd port's collection? if this is going to lead to too much corporate brouhaha then perhaps i should leave it as it is. bcmfw(8) and bt3cfw(8) man pages already tell users where they can get the firmware. thanks, max