From: Richard Weinberger <richard@nod.at>
To: David Laight <David.Laight@aculab.com>
Cc: 'Richard Weinberger' <richard.weinberger@gmail.com>,
"kevin@guarana.org" <kevin@guarana.org>,
"glaubitz@physik.fu-berlin.de" <glaubitz@physik.fu-berlin.de>,
Andy Lutomirski <luto@kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"open list:ABI/API" <linux-api@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>,
"fweimer@redhat.com" <fweimer@redhat.com>,
Mike Frysinger <vapier@gentoo.org>,
"H.J. Lu" <hjl.tools@gmail.com>,
"dalias@libc.org" <dalias@libc.org>,
"x32@buildd.debian.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@li>
Subject: Re: Can we drop upstream Linux x32 support?
Date: Fri, 14 Dec 2018 16:17:59 +0100 [thread overview]
Message-ID: <3143388.E8mgBzaflP@blindfold> (raw)
In-Reply-To: <d54d7ea7c558474583dfed0d26f05ccd@AcuMS.aculab.com>
Am Freitag, 14. Dezember 2018, 15:38:53 CET schrieb David Laight:
> From: Richard Weinberger
> > Sent: 13 December 2018 09:05
> > On Thu, Dec 13, 2018 at 6:03 AM Kevin Easton <kevin@guarana.org> wrote:
> > >
> > > On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> > > ...
> > > > I can't say anything about the syscall interface. However, what I do know
> > > > is that the weird combination of a 32-bit userland with a 64-bit kernel
> > > > interface is sometimes causing issues. For example, application code usually
> > > > expects things like time_t to be 32-bit on a 32-bit system. However, this
> > > > isn't the case for x32 which is why code fails to build.
> > >
> > > OpenBSD and NetBSD both have 64-bit time_t on 32-bit systems and have
> > > had for four or five years at this point.
> >
> > They can also do flag-day changes and break existing applications, Linux not.
>
> Not true at all.
> The binary compatibility in NetBSD is probably better than that in Linux
> and goes back a long way.
>
> For the time_t changes new system calls numbers were assigned where needed.
> The system headers and libc were updated so that recompiled code would
> use the new system calls.
>
> The only real advantage that NetBSD has is that its libc (and standard
> utilities) are released with the kernel making it much easier to get
> applications to use the new features.
>
> This was also done a very long time ago when file offsets were extended
> to 64 bits.
>
> Some of the system calls have quite a few 'compatibility' versions.
> As well as the ones for emulations of other operating systems.
> It has been possible to run copies of firefox compiled for Linux
> under NetBSD.
I stand corrected, I was under the impression that NetBSD went the same
path as OpenBSD did. Thanks for pointing this out.
Thanks,
//richard
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: David Laight <David.Laight@aculab.com>
Cc: 'Richard Weinberger' <richard.weinberger@gmail.com>,
"kevin@guarana.org" <kevin@guarana.org>,
"glaubitz@physik.fu-berlin.de" <glaubitz@physik.fu-berlin.de>,
Andy Lutomirski <luto@kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"open list:ABI/API" <linux-api@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>,
"fweimer@redhat.com" <fweimer@redhat.com>,
Mike Frysinger <vapier@gentoo.org>,
"H.J. Lu" <hjl.tools@gmail.com>,
"dalias@libc.org" <dalias@libc.org>,
"x32@buildd.debian.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: Fri, 14 Dec 2018 16:17:59 +0100 [thread overview]
Message-ID: <3143388.E8mgBzaflP@blindfold> (raw)
In-Reply-To: <d54d7ea7c558474583dfed0d26f05ccd@AcuMS.aculab.com>
Am Freitag, 14. Dezember 2018, 15:38:53 CET schrieb David Laight:
> From: Richard Weinberger
> > Sent: 13 December 2018 09:05
> > On Thu, Dec 13, 2018 at 6:03 AM Kevin Easton <kevin@guarana.org> wrote:
> > >
> > > On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> > > ...
> > > > I can't say anything about the syscall interface. However, what I do know
> > > > is that the weird combination of a 32-bit userland with a 64-bit kernel
> > > > interface is sometimes causing issues. For example, application code usually
> > > > expects things like time_t to be 32-bit on a 32-bit system. However, this
> > > > isn't the case for x32 which is why code fails to build.
> > >
> > > OpenBSD and NetBSD both have 64-bit time_t on 32-bit systems and have
> > > had for four or five years at this point.
> >
> > They can also do flag-day changes and break existing applications, Linux not.
>
> Not true at all.
> The binary compatibility in NetBSD is probably better than that in Linux
> and goes back a long way.
>
> For the time_t changes new system calls numbers were assigned where needed.
> The system headers and libc were updated so that recompiled code would
> use the new system calls.
>
> The only real advantage that NetBSD has is that its libc (and standard
> utilities) are released with the kernel making it much easier to get
> applications to use the new features.
>
> This was also done a very long time ago when file offsets were extended
> to 64 bits.
>
> Some of the system calls have quite a few 'compatibility' versions.
> As well as the ones for emulations of other operating systems.
> It has been possible to run copies of firefox compiled for Linux
> under NetBSD.
I stand corrected, I was under the impression that NetBSD went the same
path as OpenBSD did. Thanks for pointing this out.
Thanks,
//richard
next prev parent reply other threads:[~2018-12-14 15:17 UTC|newest]
Thread overview: 82+ 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 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: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-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 9:37 ` Sven Hartrumpf
2018-12-13 9:57 ` Adam Borowski
2018-12-13 18:50 ` Sven Hartrumpf
2018-12-13 12:12 ` Kevin Easton
2018-12-14 14:38 ` David Laight
2018-12-14 15:17 ` Richard Weinberger [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2018-12-11 20:38 Shawn Rutledge
2018-12-12 0:00 ` Maciej W. Rozycki
2018-12-12 9:12 Steven Newbury
2018-12-12 10:48 ` Thorsten Glaser
2018-12-12 13:27 ` Steven Newbury
2018-12-12 14:01 ` Rich Felker
2018-12-12 14:46 ` Steven Newbury
2018-12-12 16:05 ` Rich Felker
2018-12-13 16:17 tedheadster
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=3143388.E8mgBzaflP@blindfold \
--to=richard@nod.at \
--cc=David.Laight@aculab.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dalias@libc.org \
--cc=fweimer@redhat.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=kevin@guarana.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=richard.weinberger@gmail.com \
--cc=torvalds@li \
--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 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.