Oh come on, embedded systems use modules all the time, and surely you
know that. My router running OpenWRT says
root@gw:~# ipkg list | grep -c kmod
91
Therefore, simple kernel replacement can create a regression by doing
1) build 2.6.26 kernel, including all associated kernel module packages
("kmod-*")
2) install new kernel and associated kmod packages
3) watch system work as expected
4) build 2.6.27 kernel, including all associated kernel module packages
5) install new kernel and associated kmod packages
6) watch system fail
Why fail? The package file lists for kmod-* ipkg's are unaware of any
firmware needs newly added in 2.6.27.
So the driver gets packaged, but ipkg build process is completely
unaware of the additional firmware requirement until a manifest is
updated. The normal build process appears to succeed -- yet at next
boot you see that it failed.
Similar breakage for driver disks.
Similar breakage for older versions of mainstream distros (won't get
copied into initrd, with obvious results).
Does that mean you agree it's a regression? :) Sure, I'd be happy to
help fix the damage.
I am still surprised this was merged at all in its state, and am a bit
disappointed. This one
* removed choice, by removing ability to build firmware into modules
* forced a flag day build process change upon all distros/builders who
switch to >= 2.6.27. no build script updates == non-working drivers.
* the legal subtext of these changes was not mentioned at all
Generally, we don't do that. Generally, we give distros the ability to
choose between old-way and new-way during a time of transition.
Generally we make it easy for newer kernels to work on existing systems,
maximizing the [test] audience.
Jeff
--
