On Thu, 2008-07-03 at 19:42 -0700, david@lang.hm wrote:It's in linux-next now. See the CONFIG_EXTRA_FIRMWARE option. That's one of the reasons Ted's ranting about 'religious fundamentalism' is so funny -- I've actually made it _easier_ for you to combine arbitrary firmware files into your kernel. All forms of change introduce _some_ risk of breakage, of course. In this case, as usual, I've tried to be careful to avoid regressions. The most important part, obviously, was having a way to build firmware into the static kernel. When it comes to _modules_, doing that would introduce a certain amount of complexity which just doesn't seem necessary -- if you can load modules, then you have userspace, and you can use hotplug for firmware too. Especially given that so many modern drivers already _require_ you to do that, so the users understand it, and the tools like mkinitrd already cope with it -- checking MODULE_FIRMWARE() for the modules they include and including the appropriate files automatically. The alleged problem with modules seems to be _just_ about the fact that people need to run 'make firmware_install', and need to have their firmware installed. Something which all modern drivers require _anyway_, and people are used to in the general case already. It's not exactly hard; there's just the initial step of realising that the driver _you_ are using has now been updated to behave like all the others. That step is _minor_, and it doesn't actually get any easier _however_ long you postpone it. Yes, you might get 10 people in the first day tripping over it, and I'll look to see if I can make it clearer. But it's still a very minor, short-term thing. I suspect that the best option is just to hold off on updating the net drivers until later, when people already _know_ that they need to run 'make firmware_install', (or it happens automatically or something, if we go down that route). That way, Dave and Jeff shouldn't be affected by the initial transition period. There's plenty of other drivers which need updating, after all. And most maintainers are _happy_ to see the patches to bring their drivers in line with best current practice. You can. You need to stay sober for long enough to say 'Y' when it asks you if you want to build the required firmware into the kernel. And we even made that the _default_ now, for the benefit of those who can't stay sober that long. (Perhaps we'll make 'allyesconfig' the default next?) You don't need to do that any more :) -- dwmw2 --
| Heiko Carstens | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Eric W. Biederman | [PATCH 0/10] sysfs network namespace support |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
