On Fri, 2008-07-04 at 09:15 -0400, Jeff Garzik wrote:No, Jeff. That is neither new, nor a real problem. You're just posturing. That's the way it has been for a _long_ time anyway, for any modern driver which uses request_firmware(). The whole point about modules is _modularity_. Yes, that means that sometimes they depend on _other_ modules, or on firmware. The scripts which handle that kind of thing have handled inter-module dependencies, and MODULE_FIRMWARE(), for a long time now. If I ask mkinitrd to include the b43 driver in my initrd, for example, it should quite happily include both mac80211.ko and the required firmware. All I'm doing is updating some of the older drivers which don't conform to current best practice, and which still keep large chunks of data in unswappable kernel memory instead of loading it on demand. And making that more workable in the general case, but giving the _option_ of building arbitrary firmware into the kernel, for _all_ modern drivers. Your argument makes about as much sense as an argument that we should link b43.ko with mac80211.ko so that the 802.11 core code "rides along in the module's .ko file". It's just silly. -- dwmw2 --
| Kok, Auke | Re: -mm merge plans for 2.6.23 - ioat/dma engine |
| Jeff Garzik | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Matthew Garrett | [PATCH] Remove process freezer from suspend to RAM pathway |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Jens Axboe | Re: [BUG] New Kernel Bugs |
git: | |
