[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Please decide how kernel ABI should be managed

On Sun, Dec 19, 2010 at 07:30:58PM +0100, Julien BLACHE wrote:
> I am hereby asking the tech-ctte to decide how the kernel ABI should
> be managed.

Hi Julien, from the bug log it's pretty clear that there was no
possibilities of agreement between you and the kernel team, so thanks
for bringing this issue to tech-ctte.

I've a question for the kernel team, which might help some investigation
of the tech-ctte. There seem to be two intertwined issue here:

1) the general policy of kernel ABI maintenance
2) the specific smp_ops issue

You asked ruling about (1), on which there is a clear divergence of
opinions between you (as bug reporter / user) and the kernel team (as
package maintainers). Of course ruling about (1) will also address (2),
one way or the other.

Still, (2) is more urgent, as (I agree on that) it will impact upgrade
experience of Debian users like Julien, who are forced to use VMWare. No
matter who is at fault, the choice about (2) will have an impact on a
specific class of users.

My question to the kernel team is if, no matter (2), there are
*technical* reasons for not reverting the removal of the "smp_send_stop"
symbol. I understand there are "political" reasons for *not* reverting
the change, like reinforcing the position that people should not rely on
symbols not exported for out-of-tree modules. I believe it would help
the discussion to know whether there are technical blockers to the

> I think it would be best if this matter would be decided upon before
> the release of Squeeze, or not too long after it, so as to avoid
> further breakages in early kernel updates for Squeeze.


Just my 0.02€,

Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams

Attachment: signature.asc
Description: Digital signature

Reply to: