Changing kernel API / Breaking VirtualBox - update criteria violation?

[Matthew Garrett]

On Tue, Nov 22, 2011 at 08:53:13AM -0800, Toshio Kuratomi wrote:
> On Tue, Nov 22, 2011 at 04:23:28PM +0000, Matthew Garrett wrote:
> > The kernel ABI is the syscall interface, /sys and /proc. There is no 
> > stable module ABI between kernels - even with a small security update, 
> > the symbol versioning may change in such a way that the module ABI will 
> > change. Given that any interpretation of the stable update policy that 
> > prevented us from ever providing kernel security updates would be 
> > absurd, that's clearly not the correct interpretation. And if the module 
> > ABI isn't supported, nor is the API.
> > 
> That's not a logical conclusion.  As I said in both my previous emails, the
> updates policy allows the maintainer to decide that the benefits of a new
> version outwiegh the problems.  According to the updates policy the
> maintainer needs to consider that their change will cause problems for third
> party kernel module packagers and end users that are compiling their own
> kernel modules.  The policy does not require that the kernel maintainers
> weigh this more heavily than the need to provide security updates (or new
> hardware or major bugfixes).

I don't know how much clearer I can make this. The update policy applies
to the supported ABI of the package. For instance, if I have an 
application that depends on byte 0x9e0 of /bin/ls being 0xdf and an 
update breaks that, that's not a relevant consideration for the update 
policy. The kernel module interface is not a supported ABI in Fedora. 
It's simply not a relevant consideration for the update policy.

> If you're steamed up that the policy requires maintainers to consider their
> impact on end users at all, the onus is on you to make a change to the
> policy.  As long as the policy gives the maintainer the ability to explain
> how the pros and cons of updates stack up in their view, however, it doesn't
> seem nearly as bad as you make it out to be.

The policy is fine as is. The problem is your overreaching definition of 
ABI. We could make it explicit that the module interface isn't an 
exported ABI by modifying the loader so that third-party modules simply 
can't be loaded at all and then this clearly wouldn't be an issue, but I 
don't think anyone benefits from us doing that.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org