On Thursday, 3 of July 2008, David Woodhouse wrote:Yes, I know that. Yes, I'd prefer it to behave in the same way as 'make modules_install'. I'd use a config option like BUILD_FIRMWARE_BLOBS that, if set, would make the build system create firmware bin files in the same directories where the driver's .o files are located. Then, 'make firmware_install' would only copy those bin files to wherever was appropriate (eg. /lib/firmware/). Of course, there still would be a problem if there already were such firmware files at the destination, but that would have to be resolved anyway by the user wanting to install the new kernel along with the new firmware blobs. IMO 'make headers_install' is used for a different purpose. You don't have to run it to be able to use the kernel in a usual way. OTOH, everyone is familiar with the 'make modules_install' mechanics and it seems natural to use analogous mechanics for firmware blobs. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Linus Torvalds | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Linus Torvalds | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
