From owner-freebsd-arch@FreeBSD.ORG Wed Dec 21 16:33:56 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCE8A16A41F for ; Wed, 21 Dec 2005 16:33:56 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EEEB43D62 for ; Wed, 21 Dec 2005 16:33:44 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jBLGWJrm062652; Wed, 21 Dec 2005 09:32:20 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43A98393.5030502@samsco.org> Date: Wed, 21 Dec 2005 09:32:19 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <15635.1135181891@critter.freebsd.dk> In-Reply-To: <15635.1135181891@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: arch@freebsd.org Subject: Re: firmware loading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 16:33:56 -0000 Poul-Henning Kamp wrote: > In message <43A8EE23.3010202@errno.com>, Sam Leffler writes: > >>Florent Thoumie and I have been working on some generic support for >>loading firmware using kld's. You can find a proof of concept at: >> >>http://www.freebsd.org/~sam/firmware.tgz >> >>It has code to manage firmware images and load them on demand by >>requesting a kld through standard facilities. > > > Is the firmware kld unloaded again when no longer in use, or does it > stay in KVM once as long as the driver is active ? > Right now it stays resident. My understanding is that the wireless cards that this was designed for need to reload their firmware after resume. We don't have any hooks to tell drivers when the filesystem is ready, so the only non-hackish solution right now is to just keep it resident. I agree that this isn't ideal, and I would think that it would be pretty trivial to add an event handler hook to solve this. The other thing that I'm not sure about is whether this being a module dependency will prevent it from being unloaded. I'm not sure how ispfw.ko handles this. Scott