Changing kernel API / Breaking VirtualBox - update criteria violation?

[Toshio Kuratomi]

On Tue, Nov 22, 2011 at 05:12:12PM +0000, Matthew Garrett wrote:
> 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.
> 
I don't know how much clearer I can make this -- The updates policy applies
to more than the "supported ABI of a package".  For instance, if you have an
application that dependds on /bin/ls printing "?" when it encounters
a filename with a byte that cannot be decoded in the current locale and it
starts printing \001 instead, that is a relevant consideration according to
the updates 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.

The definition of ABI is not at issue.  The reach of the updates policy
itself is.  If I'm understanding you correctly you think the updates policy
applies to a much more limited scope of changes than I do.  I would suggest
that that is an indication that the updates policy needs to be reworded in
at least certain places so as to more clearly illustrate whether it has
a broad scope (in which things like ABI are examples of criteria for
deciding not to issue an update) or limited scope (in which ABI is one of
the specific criteria for decding to withhold an update.)

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111122/fd190a95/attachment.bin