Messages in this thread | | | Date | Tue, 24 Feb 2015 08:40:52 +0100 | From | Christian Borntraeger <> | Subject | Re: Linux 4.0-rc1 out.. |
| |
Am 24.02.2015 um 03:34 schrieb Mike Galbraith: > On Mon, 2015-02-23 at 16:43 +0100, Christian Borntraeger wrote: >> Am 23.02.2015 um 04:06 schrieb Linus Torvalds: >>> .. let's see how much, if anything, breaks due to the version number. >>> Probably less than during the 3.0 timeframe, but I can just imagine >>> somebody checking for meaningful versions. >>> >>> Because the people have spoken, and while most of it was complete >>> gibberish, numbers don't lie. People preferred 4.0, and 4.0 it shall >>> be. Unless somebody can come up with a good argument against it. >> >> The only argument that I can come up with is "we do not break userspace". >> For example there is this "gem" in configure.ac of valgrind: >> >> >> case "${kernel}" in >> 2.6.*|3.*) >> AC_MSG_RESULT([2.6.x/3.x family (${kernel})]) >> AC_DEFINE([KERNEL_2_6], 1, [Define to 1 if you're using Linux 2.6.x or Linux 3.x]) >> ;; >> >> 2.4.*) >> AC_MSG_RESULT([2.4 family (${kernel})]) >> AC_DEFINE([KERNEL_2_4], 1, [Define to 1 if you're using Linux 2.4.x]) >> ;; >> >> *) >> AC_MSG_RESULT([unsupported (${kernel})]) >> AC_MSG_ERROR([Valgrind works on kernels 2.4, 2.6]) >> ;; > > > Heh, if this is an argument, we have one hell of a lot of reverting to > do :) Crash for example breaks at much higher resolution, and indeed > just broke yet again. Tough titty for userspace methinks.
Well crash is not a good example as it by design goes beyond the user ABI and directly touches the kernel data structures ;-)
I am not requesting to go back to 3.*, I was just pointing out that if we apply strict rules on "we dont break userspace", the move to 3.* and 4.* was a mistake. We do provide uname26 as a workaround, so this is ok and the switch to 4 should be a lot smoother.
But better end the discussion here :-)
Christian
FWIW, valgrind svn is fixed as of yesterday (for good, so Linux 5.* 6.*.. should also work)
| |