On Tue, 19 Apr 2011, Ben Hutchings wrote:
On Tue, 2011-04-19 at 02:41 +0530, Faheem Mitha wrote: [...]If I understand this correctly, altering the config changes the kernel ABI.Sometimes. If an exported function is conditional on CONFIG_FOO, or it uses a type whose definition depends on CONFIG_FOO, then turning CONFIG_FOO on or off changes the ABI of that function, and thus of the kernel as a whole. Enabling or changing the configuration of a single driver usually doesn't change the ABI, because most drivers don't export anything.Question: wouldn't patching the kernel also change the ABI?Sometimes, yes.Therefore it is required to also change the ABI name, otherwise this is detected by the build process (Question: how does it do this?) which aborts.The kernel build process generates a 'symbol version' for each exported function or variable. This is a hash of the definitions that it depends on, and should change whenever the function's ABI changes. The kernel module loader detects incompatible modules by comparing symbol versions. The whole set of symbol versions represents the kernel ABI. We collect the symbol versions for previously uploaded packages under the directory debian/abi and then compare the new kernel with those. If the ABI name is unchanged but the ABI itself is changed - except for additions, or changes that we have marked as acceptable - then the build is aborted, as you saw.
I see. I advocate having something like this in the kernel documenation. Currently it is just a list of commands to type, and some background & explanation would be helpful.
So I set 'abiname: custom1.0' and ran fakeroot debian/rules debian/control-real and then fakeroot debian/rules source fakeroot make -f debian/rules.gen binary-arch_i386_none_686 BTW, what does fakeroot debian/rules source do?Copies and patches the upstream source.
Mention this too.
The resulting kernel package looks like linux-image-2.6.26-custom1.0-686-bigmem_2.6.26-26lenny1_i386.deb. I get warnings of the form Compatibility levels before 5 are deprecated. See extract from build log below. Does this mean it expected the abiname to start with 5, for some reason?No, this is a warning from debhelper.
Ah, Ok. debhelper wants debian/compat to be 5?
I've attempted to document this, since it currently does not appear to be. See patch to kernel handbook below. I'm sure I'm made errors, so corrections, please.[...] Thanks. I'll apply something like that, but change 'is necessary' to 'may be necessary.
I'll review your patch.
Addendum: I get this error when trying to install dpkg: dependency problems prevent configuration of linux-headers-2.6.26-custom1.0-686-bigmem: linux-headers-2.6.26-custom1.0-686-bigmem depends on linux-headers-2.6.26-custom1.0-common (= 2.6.26-26lenny1); however: Package linux-headers-2.6.26-custom1.0-common is not installed. dpkg: error processing linux-headers-2.6.26-custom1.0-686-bigmem (--install): dependency problems - leaving unconfigured Errors were encountered while processing: linux-headers-2.6.26-custom1.0-686-bigmem The debian packaging does not generate this linux-header common package.It does, just not with the rule you used. You'll have to use: make -f debian/rules.gen binary-arch_i386_none_real
I tried this, and it produces linux-headers-2.6.26-custom1.0-common_2.6.26-26lenny1_i386.deb in contrast with the original command fakeroot make -f debian/rules.gen binary-arch_i386_none_686 which produces the header and linux-image packages. Is the general syntax target_arch_featureset_real ? Why 'real'?Is this produced by a separate command because it doesn't need to be regenerated every time? It would be simpler if it was produced along with the header and linux image packages with
fakeroot make -f debian/rules.gen binary-arch_i386_none_686imo. In any case, this should also be added to the documentation. I'll attempt updates to your patch.
Regards, Faheem