All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: John Stultz <john.stultz@linaro.org>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
	ksummit-discuss@lists.linuxfoundation.org,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder
Date: Wed, 13 Aug 2014 03:06:53 +0100	[thread overview]
Message-ID: <1407895613.3017.138.camel@deadeye.wl.decadent.org.uk> (raw)
In-Reply-To: <CALAqxLUcfaJnxdmkn6mucepNk3QaCQdcSPLRjjeKsk_OTp=uLA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

On Tue, 2014-08-12 at 17:01 -0700, John Stultz wrote:
[...]
> The downsides here are many. The distros will probably hate this idea,

I certainly hate the idea of adding another 32-bit port to Debian.
I think that it's OK for traditional distros to say 'just upgrade to
64bit' while you solve the problem for 32-bit embedded systems where
there's probably little demand for supporting multiple ABIs at once.

>  as it requires rebuilding the world, and maintaining another legacy
> architecture support. I’m also not completely sure how robust
> multi-arch packaging is in the face of having to handle 3-4
> architectures on one system.

dpkg multiarch covers this just fine, while I believe RPM is limited to
biarch.

> On the kernel side, it also adds more complexity, where we have to add
> even more complex compat support for 64bit systems to handle all the
> various 32bit applications possible.
[...]

Didn't we need to do this already to support x32?  Have compat ioctls
involving time been botched?

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Ben Hutchings <ben@decadent.org.uk>
To: John Stultz <john.stultz@linaro.org>
Cc: ksummit-discuss@lists.linuxfoundation.org,
	"Joseph S. Myers" <joseph@codesourcery.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder
Date: Wed, 13 Aug 2014 03:06:53 +0100	[thread overview]
Message-ID: <1407895613.3017.138.camel@deadeye.wl.decadent.org.uk> (raw)
In-Reply-To: <CALAqxLUcfaJnxdmkn6mucepNk3QaCQdcSPLRjjeKsk_OTp=uLA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

On Tue, 2014-08-12 at 17:01 -0700, John Stultz wrote:
[...]
> The downsides here are many. The distros will probably hate this idea,

I certainly hate the idea of adding another 32-bit port to Debian.
I think that it's OK for traditional distros to say 'just upgrade to
64bit' while you solve the problem for 32-bit embedded systems where
there's probably little demand for supporting multiple ABIs at once.

>  as it requires rebuilding the world, and maintaining another legacy
> architecture support. I’m also not completely sure how robust
> multi-arch packaging is in the face of having to handle 3-4
> architectures on one system.

dpkg multiarch covers this just fine, while I believe RPM is limited to
biarch.

> On the kernel side, it also adds more complexity, where we have to add
> even more complex compat support for 64bit systems to handle all the
> various 32bit applications possible.
[...]

Didn't we need to do this already to support x32?  Have compat ioctls
involving time been botched?

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

  reply	other threads:[~2014-08-13  2:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-13  0:01 [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder John Stultz
2014-08-13  2:06 ` Ben Hutchings [this message]
2014-08-13  2:06   ` Ben Hutchings
2014-08-13  4:03   ` John Stultz
2014-08-13  4:03     ` John Stultz
2014-08-13 20:06   ` Arnd Bergmann
2014-08-13 20:06     ` Arnd Bergmann
2015-09-19  0:04     ` H. Peter Anvin
2015-09-19  0:04       ` H. Peter Anvin
2014-08-13 12:05 ` Joseph S. Myers
2014-08-13 12:05   ` Joseph S. Myers
2014-08-13 15:37 ` [Ksummit-discuss] " Joseph S. Myers
2014-08-13 15:37   ` Joseph S. Myers
2014-08-13 15:37   ` Joseph S. Myers

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=1407895613.3017.138.camel@deadeye.wl.decadent.org.uk \
    --to=ben@decadent.org.uk \
    --cc=john.stultz@linaro.org \
    --cc=joseph@codesourcery.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.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.