All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: NeilBrown <neilb@suse.com>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>,
	Andy Lutomirski <luto@kernel.org>
Subject: Re: [Ksummit-discuss] [MAINTAINER TOPIC] ABI feature gates?
Date: Fri, 11 Aug 2017 16:10:51 -0700	[thread overview]
Message-ID: <CA+55aFxFh8K_HxXEDXGizCj097u7VE8NZB8LpAVEdA2aSYgHHg@mail.gmail.com> (raw)
In-Reply-To: <87zib6pm5s.fsf@notabene.neil.brown.name>

On Fri, Aug 11, 2017 at 1:02 AM, NeilBrown <neilb@suse.com> wrote:
>
> What do you mean by "upgrade"?
> Can I upgrade from 3.15 to 3.16-rc1?  If not, why not?

Yes..

Of course, bugs happen, and then they get fixed.

But yes, even including things like -rc1 (or just "random untagged
kernel of the day") you should

 (a) feel safe in always upgrading to any higher version (I *hope* you
can always also downgrade to a lower kernel version, but obviously at
some point user space may start depending on newer features that
simply don't exist in older kernels).

 (b) also feel that if something breaks, it's a bug, and people will
take it seriously and not dismiss it with some crazy "N+1 version"
excuse.

There are some cases where we may not be able to avoid breakage: the
main two are "security issues" and "insanely old hardware".

And even for security issues, we try really really hard to avoid breakage.

And the key word in "insanely old hardware" is that "insanely" part.
At some point it just gets too hard to test (and sometimes the
hardware is too broken, like the original i386 non-working supervisor
page fault workarounds).

Now, it can get really interesting if somebody notices an ABI change
so late that others have started to depend on that ABI change. At that
point, it's a "damned if you do, damned if you don't". We've actually
been able to handle even that occasionally (by just adjusting behavior
automatically based on some pattern), but at some point it obviously
is impossible to fix both cases.

And then I say "if it took you three years to upgrade and notice a
behavioral change that nobody else noticed, it's no longer _our_
fault".

So there is _some_ onus on people actually testing and reporting these
things, but I can't off-hand actually remember any case of this really
being a major issue. So it's largely a theoretical thing.

                Linus

  reply	other threads:[~2017-08-11 23:10 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-04  1:16 [Ksummit-discuss] [MAINTAINER TOPIC] ABI feature gates? Andy Lutomirski
2017-08-04  1:30 ` Greg KH
2017-08-04  4:15   ` Andy Lutomirski
2017-08-04  5:08   ` Sergey Senozhatsky
2017-08-04  8:23   ` Daniel Vetter
2017-08-04  2:26 ` Theodore Ts'o
2017-08-04  3:27   ` Stephen Rothwell
2017-08-04  5:13     ` Julia Lawall
2017-08-04 14:20       ` Theodore Ts'o
2017-08-04 15:47         ` Julia Lawall
2017-08-04  8:42   ` Jiri Kosina
2017-08-04  8:53     ` Hannes Reinecke
2017-08-04 16:04       ` Greg KH
2017-08-04 17:14         ` Theodore Ts'o
2017-08-04 17:53           ` Greg KH
2017-08-04 22:52             ` Joe Perches
2017-08-09 20:06             ` Geert Uytterhoeven
2017-08-14 19:49         ` Steven Rostedt
2017-08-14 19:51           ` Linus Torvalds
2017-08-15  7:13             ` Julia Lawall
2017-08-04  8:57     ` Julia Lawall
2017-08-04 11:27       ` Michael Kerrisk (man-pages)
2017-08-09  0:00 ` NeilBrown
2017-08-09 11:54   ` Laurent Pinchart
2017-08-14 20:07     ` Steven Rostedt
2017-08-09 20:21   ` Linus Torvalds
2017-08-11  6:21     ` NeilBrown
2017-08-11  6:39       ` Linus Torvalds
2017-08-11  8:02         ` NeilBrown
2017-08-11 23:10           ` Linus Torvalds [this message]
2017-08-14  4:19             ` NeilBrown
2017-08-14 18:34               ` Linus Torvalds
2017-08-14 18:40                 ` Linus Torvalds
2017-08-14 23:23                   ` Andy Lutomirski
2017-08-15  0:54                     ` Linus Torvalds
2017-08-15 16:11                       ` Andy Lutomirski
2017-08-15 18:26   ` Michael Kerrisk (man-pages)

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=CA+55aFxFh8K_HxXEDXGizCj097u7VE8NZB8LpAVEdA2aSYgHHg@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=luto@kernel.org \
    --cc=neilb@suse.com \
    /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.