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.
> 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.
> 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.
> 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.
> 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
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part