Processed: Please decide how kernel ABI should be managed
Processing commands for cont...@bugs.debian.org:
reopen 607368
Bug #607368 {Done: maximilian attems m...@stro.at} [src:linux-2.6] linux-2.6:
silent ABI change in 2.6.32.26 breaks external modules (smp_ops changes)
tags 607368 - wontfix
Bug #607368 [src:linux-2.6] linux-2.6: silent ABI change in 2.6.32.26 breaks
external modules (smp_ops changes)
Removed tag(s) wontfix.
reassign 607368 tech-ctte
Bug #607368 [src:linux-2.6] linux-2.6: silent ABI change in 2.6.32.26 breaks
external modules (smp_ops changes)
Bug reassigned from package 'src:linux-2.6' to 'tech-ctte'.
Bug No longer marked as found in versions linux-2.6/2.6.32-28.
retitle 607368 Please decide how kernel ABI should be managed
Bug #607368 [tech-ctte] linux-2.6: silent ABI change in 2.6.32.26 breaks
external modules (smp_ops changes)
Changed Bug title to 'Please decide how kernel ABI should be managed' from
'linux-2.6: silent ABI change in 2.6.32.26 breaks external modules (smp_ops
changes)'
thanks
Stopping processing here.
Please contact me if you need assistance.
--
607368: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607368
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/handler.s.c.12927834455926.transcr...@bugs.debian.org
Bug#607368: Please decide how kernel ABI should be managed
On Sun, Dec 19, 2010 at 07:30:58PM +0100, Julien BLACHE wrote: reopen 607368 tags 607368 - wontfix reassign 607368 tech-ctte retitle 607368 Please decide how kernel ABI should be managed thanks Hi, I am hereby asking the tech-ctte to decide how the kernel ABI should be managed. Case in point: the kernel team decided to ignore changes to the smp_ops symbol in 2.6.32-28 which broke external modules (vmware) without any prior warning. FWIW; the ABI handling has been fairly strict during the lifetime of a stable release. I'm not aware that the same situation has occured during the Etch or Lenny lifetime. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101219185120.ga10...@galadriel.inutil.org
Bug#607368: 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
revert.
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.
+1
Just my 0.02€,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{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
signature.asc
Description: Digital signature
Bug#607368: Please decide how kernel ABI should be managed
On Sun, 2010-12-19 at 20:19 +0100, Stefano Zacchiroli wrote: 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 revert. [...] smp_send_stop was never exported in its own right. The change to smp_ops was made as part of this bug fix: commit ae832c21a08514fd11d2d1d6e217c8a537764bb0 Author: Alok Kataria akata...@vmware.com Date: Mon Oct 11 14:37:08 2010 -0700 x86, kexec: Make sure to stop all CPUs before exiting the kernel commit 76fac077db6b34e2c6383a7b4f3f4f7b7d06d8ce upstream. x86 smp_ops now has a new op, stop_other_cpus which takes a parameter wait this allows the caller to specify if it wants to stop until all the cpus have processed the stop IPI. This is required specifically for the kexec case where we should wait for all the cpus to be stopped before starting the new kernel. We now wait for the cpus to stop in all cases except for panic/kdump where we expect things to be broken and we are doing our best to make things work anyway. This patch fixes a legitimate regression, which was introduced during 2.6.30, by commit id 4ef702c10b5df18ab04921fc252c26421d4d6c75. Signed-off-by: Alok N Kataria akata...@vmware.com LKML-Reference: 1286833028.1372.20.ca...@ank32.eng.vmware.com Cc: Eric W. Biederman ebied...@xmission.com Cc: Jeremy Fitzhardinge jer...@xensource.com Signed-off-by: H. Peter Anvin h...@linux.intel.com Signed-off-by: Greg Kroah-Hartman gre...@suse.de (ooh, irony). Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#607368: Please decide how kernel ABI should be managed
On Sun, Dec 19, 2010 at 08:19:22PM +0100, Stefano Zacchiroli wrote: 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 we try to avoid ABI bumps at our best. especially in times of release the ABI is kind of frozen due to d-i requirements. There is no way so shortly before the release we would bump ABI. upstream has no ABI rule best read in Documentation/stable_api_nonsense.txt thus stable updates to indeed change ABI. 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. The submitter shows a clear confusion between the requirements of a shared lib userspace and the linux-2.6 kernel. Furthermore it is indeed quite unclear if said company is not effectively violating GPL and several core dev do indeed think so. -- maks -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101219233806.ga20...@vostochny.stro.at
