From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 18:25:59 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 7C20A16A41F for ; Mon, 21 Nov 2005 18:25:59 +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 11D8D43D6D for ; Mon, 21 Nov 2005 18:25:58 +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 jALIPu8U021631; Mon, 21 Nov 2005 11:25:56 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43821134.6040306@samsco.org> Date: Mon, 21 Nov 2005 11:25:56 -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: Warner Losh References: <8664qmja7y.fsf@xps.des.no> <4381F060.5040107@samsco.org> <4381FEDF.7080607@root.org> <20051121.111955.74713410.imp@bsdimp.com> In-Reply-To: <20051121.111955.74713410.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h 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: Mon, 21 Nov 2005 18:25:59 -0000 Warner Losh wrote: > jhb>John Baldwin > jhb> The easiest way to accomplish this is for your driver to send a > jhb> message to devd requesting that the firmware be reloaded on > jhb> resume since devd won't run until the kernel is fully back up. > > des>Dag-Erling Smørgrav > des> ...or keep the firmware image in memory after loading it the first > des> time around. > > scottl>Scott Long > scottl> Or have the firmware be embedded in a KLD, like ispfw. > > nate>Nate Lawson > nate> I think I've now been repeated by everyone in the conversation. :) > > Only those people that think it is a good idea have repeated it. > > nate> So maybe it's time to solve this? Move discussion to arch@? > > I don't like the kld option. People have been talking about doing > this since about 4.2 and nothing has happened to make it generic. > > The good things about it are that the driver can request that modules > be loaded and unloaded. Once loaded, the driver can go directly to a > binary representation of the firmware. These are both good points. > > The bad points about this is that you have to generate the firmware > kld module. This will require a per-driver program to parse the > firmware and some design to place the data into data structures that > the driver can use to bang the data into the card. It would mean > creating two copies of the firmware because most people will install > the new firmware, then run this program and install the new kld (maybe > the kld generation program would run each installkernel, since you > never know what it depends on and when that might change). Also, you > have the potential for version skew between the kld and the firmware. > There's one more level of indirection that you need to worry about > when you go the kld route. > > The firmware parsing code tends to be relatively simple and may need > access to multiple files, as well as the actual hardware. The wi > firmware loader, for example, needs to patch certain values from the > card into the wi images before they will work (the current > hand-tweaked symbol CF card has had these re-applied). > > To solve the race with "/", one could easily just queue the driver > loading to a taskqueue. I don't think that the taskqueues aren't > running until after the resume process is complete. Even if they are, > and you block waiting for / to come back, it wouldn't be the resume > path that's blocking. One could also use devd for this, but if the > driver already knows how to loads its firmware, that seems like an > overly complicated solution. > > Warner Making the driver aware of the filesystem layout is a bad idea. Encapsulating data into a KLD is not hard to do. Scott