Date: Wed, 21 Dec 2005 09:20:42 -0800 From: Sam Leffler <sam@errno.com> To: Scott Long <scottl@samsco.org> Cc: arch@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Re: firmware loading Message-ID: <43A98EEA.5070405@errno.com> In-Reply-To: <43A98393.5030502@samsco.org> References: <15635.1135181891@critter.freebsd.dk> <43A98393.5030502@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote: > 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. Actually, it is unloaded on last reference. This is controlled by the caller (there's a flag to firmware_put that says it's ok to unload). Unloading on last ref is the most tricky part of the code as I wanted to handle multiple firmware images packaged in a single kld and that requires some care to be robust. For now consumers need to be somewhat aware of how multi-image kld's are packaged; they must order their get+put calls to put last on the "master image" in a kld. Using kld's to do this adds a level of indirection (over just reading directly from files) but also has lots of advantages. You can trivially link stuff statically into the kernel. You can pre-load stuff from the loader. You can print copyright notices to the console on load. You can also do things like compress the firmware in the kld. The big win is having a common api that hides the implementation details. In this regard the code needs some cleanup so consumers don't have to include linker.h to get the definition of linker_file_t and so they don't know about implementation details. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43A98EEA.5070405>