All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	jseward@acm.org
Subject: Re: Linux 4.0-rc1 out..
Date: Mon, 23 Feb 2015 16:43:20 +0100	[thread overview]
Message-ID: <54EB4A98.6020300@de.ibm.com> (raw)
In-Reply-To: <CA+55aFzS==STcTbwabdvw=7_xX08kkUd=g2Q4XbWJzKbpjyN1A@mail.gmail.com>

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])
                    ;;
        esac


This seems to be historic and unused now in the code base. I will send a
patch to valgrind-devel, that just gets rid of this check, but the check
is in all released versions of valgrind and probably others. I think
we do not care that much about failures when building valgrind on top of
systems running 2.2. If we do, I can certainly add a specific check for
1.*,2.0,2.1,2.2,2.3 that bails out then.


Christian


  parent reply	other threads:[~2015-02-23 15:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-23  3:06 Linux 4.0-rc1 out Linus Torvalds
2015-02-23  5:15 ` Stephen Rothwell
2015-02-23  5:15   ` Stephen Rothwell
2015-02-23  8:22   ` Sedat Dilek
2015-02-23 23:14   ` Olof Johansson
2015-02-24 19:40   ` Steven Rostedt
2015-02-23  8:15 ` Geert Uytterhoeven
2015-02-23 12:56 ` Arend van Spriel
2015-02-23 14:19   ` Sven-Haegar Koch
2015-02-23 15:43 ` Christian Borntraeger [this message]
2015-02-24  2:34   ` Mike Galbraith
2015-02-24  7:40     ` Christian Borntraeger
2015-02-24 10:49       ` François Valenduc
2015-02-24 17:05         ` François Valenduc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54EB4A98.6020300@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=jseward@acm.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.