From mboxrd@z Thu Jan 1 00:00:00 1970 From: Erik van Konijnenburg Date: Sat, 05 Mar 2005 15:10:07 +0000 Subject: Re: firmware and initrd [was Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts] Message-Id: <20050305161007.J23922@banaan.localdomain> List-Id: References: <20050224224343.B7339@banaan.localdomain> In-Reply-To: <20050224224343.B7339@banaan.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Fri, Mar 04, 2005 at 02:16:47PM +0300, Roman Kagan wrote: > On Fri, Feb 25, 2005 at 04:18:21PM -0800, Andrew Vasquez wrote: > > Actually, the qla2[123]00.ko, qla2322.ko and qla6312.ko files only > > existed as 'firmware-loader' modules. The core driver routines went > > into qla2xxx.ko. My hope is that once the driver transitions to the > > request_firmware() interface, the firmware-loader modules get dropped > > and the we're left with a single qla2xxx.ko module which will > > request_firmware() the proper image type based on device-id: > > This brings up another question: if the only difference between the > devices is the firmware image they need, and otherwise the driver can be > made generic (dunno if this is the case for qla2xxx, but I've seen a few > drivers like this), should the driver request_firmware() by > device-specific names, or should it rather request a generic name, and > the hotplug firmware agent would have to provide the correct image based > on device IDs available via sysfs or environment? > > In other words, where should the knowledge about the matching between > the device IDs and the required firmware go into: the driver or the > firmware agent? For the initrd generator, it's more convenient to have the matching done by the firmware agent. It also seems elegant to select firmware using the same kind of matching that we now do in modules.aliases. Reasoning as follows: "It's not the module that needs the firmware, but the device. Annotate the firmware with the devices it supports, and it becomes easy to determine which firmware needs to go on the initrd image. It also makes for easier upgrades: when qla9999 starts shipping, just distribute the firmware without need for a kernel upgrade." Unfortunately there's a counter argument: the firmware also can expose a kind of API to the driver module. The current device matching algorithms (fnmatch against modules.alias) do not make it possible to express that the qla2xxx module needs version 3.04 or later of the firmware. Perhaps the request_firmware call should specify a device id plus an API version? Note that I'm writing from a limited perspective: just initrd. Lets see what the people who actually work with firmware think. Regards, Erik ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel