David Woodhouse wrote:That's a lot of "should" and "in most cases" and "in a ideal world". What happens when the new firmware is buggy for example and prevents booting of the system? And in the cases where it doesn't work like you describe? Simply overwriting it means there would be no simple way back. Even if it breaks for only 1% of the users that would be pretty bad for Linux. Besides it means the possible combinations that have to be tested increases significantly. Doesn't sound like a good plan to me. Besides the problems that it would causes for package management of course (you would force separate packages on everybody versus just keeping the firmware in the kernel package) -Andi -- 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
| Rafael J. Wysocki | [Bug #10493] mips BCM47XX compile error |
| Ingo Molnar | [patch 02/13] syslets: add syslet.h include file, user API/ABI definitions |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Andrea Arcangeli | [PATCH 00 of 11] mmu notifier #v16 |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Linus Torvalds | Re: [GIT]: Networking |
| Mark Lord | Re: [BUG] New Kernel Bugs |
