linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: "Thomas Schöbel-Theuer" <thomas@schoebel-theuer.de>,
	"Andy Lutomirski" <luto@kernel.org>, "X86 ML" <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Linux API" <linux-api@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Borislav Petkov" <bp@alien8.de>,
	"Florian Weimer" <fweimer@redhat.com>,
	"Mike Frysinger" <vapier@gentoo.org>,
	"H. J. Lu" <hjl.tools@gmail.com>, "Rich Felker" <dalias@libc.org>,
	x32@buildd.debian.org, "Arnd Bergmann" <arnd@arndb.de>,
	"Will Deacon" <will.deacon@arm.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: Can we drop upstream Linux x32 support?
Date: Tue, 22 Jan 2019 14:34:11 +0100	[thread overview]
Message-ID: <d6542485-87ba-7d57-29bb-4077bda17809@metux.net> (raw)
In-Reply-To: <6577ac4f-524c-37f4-a4d0-6eb94ec7d9a5@schoebel-theuer.de>

On 14.12.18 22:16, Thomas Schöbel-Theuer wrote:

Hi,

> Currently, we have a few thousands of servers relying on 32bit ABIs in> some thousands of VMs and/or containers of various types (LXC,
OpenVZ,> etc).
Similar w/ my clients, but in Industrie/Embedded/i4.0 world. We have
thousands of devices in the field, that need support for at least a
decade.

Right now, I'm working on a new device, that - even having a 64bit cpu -
will still run 32bit userland for various reasons (memory footprint
is one of them).

Even on the data center side, where we have *a lot* of containers
(eg. container-based microservices on minimal distros like alpine
or ptxdist - as well as many different, often highly specialized,
legacy applications), 32bit userland indeed is a major factor.

Dropping it would have huge economic consequences:

* massive costs for re-deployment / migration of thousands of different
  applications
* field roll of thousands of different embedded / industrial devices,
  as a major cpu arch
* huge increase in memory consumption and io load in container-
  based microservice environments
* loosing x86 for a huge portion of the embedded / small devices world

I don't even dare to estimate the economic damage. (not even speaking
about reputation loss of the Linux community)

> Here is my private opinion, not speaking for 1&1: at some point the> future, 32bit userspace support needs to be dropped anyway, somewhen
in> future. This is inevitable in the very long term.

Very, very, long term. Just the devices I'm coping w/ will have
remaining lifetime of at least 10..15 years. That's a really long time
in IT world. Nobody knows whether x86 at all will play a big role then.

> 1) please release / declare a new LTS kernel, with upstream support for
> at least 5 years (as usual). Currently, only 4.4 and 4.9 are marked as
> LTS. Either mark another existing stable kernel as LTS, or a future one.

That might be okay in enterprise world (even though, here I'm regularily
stumbling across much older code in production), but in industrial
world, the product lifetimes are much longer - 20+yrs years
usualstandard.are pretty common.

--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

      parent reply	other threads:[~2019-01-22 13:34 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11  1:23 Can we drop upstream Linux x32 support? Andy Lutomirski
2018-12-11  1:40 ` Linus Torvalds
2018-12-11  2:22   ` hpa
2018-12-11  8:16   ` Florian Weimer
2018-12-11 21:53   ` Thorsten Glaser
2018-12-11 23:22     ` Andy Lutomirski
2018-12-11 23:35       ` Thorsten Glaser
2018-12-11 23:55         ` Arnd Bergmann
2018-12-12  2:24         ` Andy Lutomirski
2018-12-12  2:33           ` Thorsten Glaser
2018-12-12  9:04             ` Arnd Bergmann
2018-12-12 18:14               ` Joseph Myers
2018-12-12 18:50                 ` Ivan Ivanov
2018-12-12 19:12                   ` Andy Lutomirski
2018-12-12 19:18                     ` Ivan Ivanov
2018-12-12 16:39             ` Andy Lutomirski
2018-12-12 16:52               ` Rich Felker
2018-12-12 18:03                 ` Andy Lutomirski
2018-12-13 12:40                   ` Catalin Marinas
2018-12-13 15:57                     ` Rich Felker
2018-12-13 16:04                       ` Florian Weimer
2018-12-13 16:28                         ` Rich Felker
2018-12-14 11:42                           ` Florian Weimer
2018-12-14 16:13                             ` Rich Felker
2018-12-13 18:42                         ` Joseph Myers
2018-12-15  4:53               ` Thorsten Glaser
2018-12-11 23:38       ` Rich Felker
2018-12-11 23:40     ` Maciej W. Rozycki
2018-12-13 14:38   ` Olof Johansson
2018-12-13 15:46     ` Lance Richardson
2018-12-13 16:11   ` Richard Purdie
2018-12-11  3:14 ` H.J. Lu
2018-12-11  5:35   ` Andy Lutomirski
2018-12-11  9:02     ` Arnd Bergmann
2018-12-11 11:32       ` Catalin Marinas
2018-12-11 11:37         ` Florian Weimer
2018-12-11 11:52           ` Catalin Marinas
2018-12-11  5:46 ` Christian Brauner
2018-12-11 10:29 ` John Paul Adrian Glaubitz
2018-12-11 10:37   ` Florian Weimer
2018-12-11 10:44     ` John Paul Adrian Glaubitz
2018-12-11 21:59   ` Thorsten Glaser
2018-12-11 23:33     ` Rich Felker
2018-12-13  5:03   ` Kevin Easton
2018-12-13  9:05     ` Richard Weinberger
2018-12-13 12:12       ` Kevin Easton
2018-12-14 14:38       ` David Laight
2018-12-14 15:17         ` Richard Weinberger
2018-12-13 16:02   ` Rich Felker
2018-12-14 14:13     ` Bernd Petrovitsch
2018-12-14 16:17       ` Rich Felker
2018-12-14 16:29         ` Bernd Petrovitsch
2018-12-14 16:38         ` Florian Weimer
2018-12-14 16:55           ` Rich Felker
2018-12-14 18:58             ` Andy Lutomirski
2018-12-14 19:59               ` Lance Richardson
2018-12-14 20:13               ` Linus Torvalds
2018-12-14 21:27                 ` Andy Lutomirski
2018-12-14 21:16 ` Thomas Schöbel-Theuer
2018-12-14 21:24   ` Andy Lutomirski
2018-12-14 21:41     ` Thomas Schöbel-Theuer
2018-12-15  7:41       ` Thomas Schoebel-Theuer
2018-12-15 15:30         ` Andy Lutomirski
2019-01-09 12:41   ` Florian Weimer
2019-01-09 16:02     ` Rich Felker
2019-01-22 13:34   ` Enrico Weigelt, metux IT consult [this message]

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=d6542485-87ba-7d57-29bb-4077bda17809@metux.net \
    --to=lkml@metux.net \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=dalias@libc.org \
    --cc=fweimer@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=thomas@schoebel-theuer.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vapier@gentoo.org \
    --cc=will.deacon@arm.com \
    --cc=x32@buildd.debian.org \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).