On Tuesday 15 July 2008, David Woodhouse wrote:With the disclaimer that I really haven't researched this all that much I think we'll end up finding that a multi-level model is needed. Something like: - /lib/firmware: intended for externally provided firmware and local overrides; try to load from there first (version checks may fail) - /lib/modules/firmware: not sure if this level is necessary, but could be useful for e.g. firmware for out-of-tree drivers - /lib/modules/$kver/firmware or /lib/modules/$kver/$modulepath: firmware built (and possibly packaged together with the kernel Some scheme like this would introduce at least some sanity when it comes to keeping control of what is installed and provided (and may therefore be removed) by what and to avoid the question "how the hell did that file get there and do I still actually need it with my current kernels?". It sounds to me like $(INSTALL_FW_PATH) is a good start, but maybe even too flexible as it does not define a standard: it allows user spaces of different distros to diverge which at some point will create its own nightmares. It's also not flexible enough as it only supports a single location for firmware while clearly there can be different sources of firmware. Cheers, FJP --
| Avi Kivity | [PATCH 08/54] KVM: Portability: Move unalias_gfn to arch dependent file |
| Jon Smirl | 463 kernel developers missing! |
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Antonio Almeida | HTB accuracy for high speed |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
