From: Catalin Marinas <catalin.marinas@arm.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
John Stultz <john.stultz@linaro.org>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-discuss] (Resend) 2038 Kernel Summit Discussion Fodder
Date: Wed, 13 Aug 2014 10:18:37 +0100 [thread overview]
Message-ID: <20140813091837.GA18495@arm.com> (raw)
In-Reply-To: <CALCETrVP64FSJWyHHbm0R-2qTzN1Q5PwXh4k9+qjg1Q8bSud2w@mail.gmail.com>
On Wed, Aug 13, 2014 at 02:37:11AM +0100, Andy Lutomirski wrote:
> On Tue, Aug 12, 2014 at 6:33 PM, <josh@joshtriplett.org> wrote:
> > On Tue, Aug 12, 2014 at 05:08:53PM -0700, John Stultz wrote:
> >> A more aggressive version of the previous proposal is what I’m calling the
> >> “New Virtual-Architecture” approach, basically extending the versioning
> >> control from the linker down into the kernel as well. It would be adding a
> >> new “virtual-architecture” to the kernel, not entirely unlike how x32 is
> >> supported on x86_64 systems. We would create entirely new ABI and
> >> architecture name in the kernel (think something like “armllt” or
> >> “i386llt”). We would preserve compatibility for legacy applications via
> >> personalities, similar mechanism as the compat_ interface used to support
> >> 32bit applications on 64bit kernels. In this case, we wouldn’t introduce
> >> new 64 bit syscalls in the kernel, as the existing interfaces would just be
> >> typed correctly for our new virtual architecture, but we would have
> >> duplicate syscall interfaces via the compat interfaces. The extra
> >> complexity would also be that we would have to support new 32bit compat
> >> environment on 64bit systems. Userspace would be completely rebuilt to
> >> support the new -llt architecture, and compatibility for legacy
> >> applications would be done via the same multiarch packaging as is done now
> >> for running 32bit applications on 64bit systems.
> >
> > I wonder: could we make this new architecture effectively use the
> > signatures of the 64-bit syscalls (similar to x32), just with a 32-bit
> > calling convention?
>
> Doesn't x32 do the reverse? It invokes *compat* syscalls using a
> 64-bit calling convention.
Not entirely. It uses 64-bit syscalls primarily with compat only when
sharing structures containing pointers. We are working on something
similar for arm64 (called the ILP32 ABI).
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Josh Triplett <josh@joshtriplett.org>,
John Stultz <john.stultz@linaro.org>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
"Joseph S. Myers" <joseph@codesourcery.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-discuss] (Resend) 2038 Kernel Summit Discussion Fodder
Date: Wed, 13 Aug 2014 10:18:37 +0100 [thread overview]
Message-ID: <20140813091837.GA18495@arm.com> (raw)
In-Reply-To: <CALCETrVP64FSJWyHHbm0R-2qTzN1Q5PwXh4k9+qjg1Q8bSud2w@mail.gmail.com>
On Wed, Aug 13, 2014 at 02:37:11AM +0100, Andy Lutomirski wrote:
> On Tue, Aug 12, 2014 at 6:33 PM, <josh@joshtriplett.org> wrote:
> > On Tue, Aug 12, 2014 at 05:08:53PM -0700, John Stultz wrote:
> >> A more aggressive version of the previous proposal is what I’m calling the
> >> “New Virtual-Architecture” approach, basically extending the versioning
> >> control from the linker down into the kernel as well. It would be adding a
> >> new “virtual-architecture” to the kernel, not entirely unlike how x32 is
> >> supported on x86_64 systems. We would create entirely new ABI and
> >> architecture name in the kernel (think something like “armllt” or
> >> “i386llt”). We would preserve compatibility for legacy applications via
> >> personalities, similar mechanism as the compat_ interface used to support
> >> 32bit applications on 64bit kernels. In this case, we wouldn’t introduce
> >> new 64 bit syscalls in the kernel, as the existing interfaces would just be
> >> typed correctly for our new virtual architecture, but we would have
> >> duplicate syscall interfaces via the compat interfaces. The extra
> >> complexity would also be that we would have to support new 32bit compat
> >> environment on 64bit systems. Userspace would be completely rebuilt to
> >> support the new -llt architecture, and compatibility for legacy
> >> applications would be done via the same multiarch packaging as is done now
> >> for running 32bit applications on 64bit systems.
> >
> > I wonder: could we make this new architecture effectively use the
> > signatures of the 64-bit syscalls (similar to x32), just with a 32-bit
> > calling convention?
>
> Doesn't x32 do the reverse? It invokes *compat* syscalls using a
> 64-bit calling convention.
Not entirely. It uses 64-bit syscalls primarily with compat only when
sharing structures containing pointers. We are working on something
similar for arm64 (called the ILP32 ABI).
--
Catalin
next prev parent reply other threads:[~2014-08-13 9:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 0:08 [Ksummit-discuss] (Resend) 2038 Kernel Summit Discussion Fodder John Stultz
2014-08-13 0:08 ` John Stultz
2014-08-13 1:33 ` [Ksummit-discuss] " josh
2014-08-13 1:33 ` josh
2014-08-13 1:37 ` Andy Lutomirski
2014-08-13 1:37 ` Andy Lutomirski
2014-08-13 9:18 ` Catalin Marinas [this message]
2014-08-13 9:18 ` Catalin Marinas
2014-08-13 3:45 ` John Stultz
2014-08-13 3:45 ` John Stultz
2014-08-13 20:27 ` Arnd Bergmann
2014-08-13 20:27 ` Arnd Bergmann
2014-08-13 21:35 ` Arnd Bergmann
2014-08-13 21:35 ` Arnd Bergmann
2014-08-27 18:34 ` [Ksummit-discuss] " John Stultz
2014-08-27 18:34 ` John Stultz
2014-08-23 22:26 ` [Ksummit-discuss] " Pavel Machek
2014-08-23 22:26 ` Pavel Machek
2014-09-08 17:55 ` [Ksummit-discuss] " One Thousand Gnomes
2014-09-08 17:55 ` One Thousand Gnomes
2014-09-08 18:07 ` [Ksummit-discuss] " H. Peter Anvin
2014-09-08 18:07 ` H. Peter Anvin
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=20140813091837.GA18495@arm.com \
--to=catalin.marinas@arm.com \
--cc=john.stultz@linaro.org \
--cc=joseph@codesourcery.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
/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.