mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: sfr@canb.auug.org.au, linux-kernel@vger.kernel.org,
	anton@samba.org, ak@muc.de, davidm@hpl.hp.com,
	schwidefsky@de.ibm.com, ralf@gnu.org, willy@debian.org
Subject: Re: [PATCH] Start of compat32.h (again)
Date: 01 Dec 2002 20:46:40 -0800	[thread overview]
Message-ID: <1038804400.4411.4.camel@rth.ninka.net> (raw)
In-Reply-To: <Pine.LNX.4.44.0212011047440.12964-100000@home.transmeta.com>

On Sun, 2002-12-01 at 10:54, Linus Torvalds wrote:
> But if the file is in kernel/xxxx, it 
> will be noticed - at least as well as it would be if it was uglifying 
> regular files with #ifdef's.

Ok, this I accept.

> Face it, the "compat" stuff is _secondary_. If it breaks, it breaks.

Secondary for x86, sure.

But for Sparc64 and PPC64, the 32-bit userland is currently still
the primary one, so when compat32 breaks the whole system hits the
toilet.

That isn't going to change.  The 32-bit apps are a) smaller and b)
run much faster.  So for simple things like the basic userland apps
like 'ls', the shell, etc. it simply makes no sense to compile them
64-bit.  It just results in big huge 64-bit binaries when 32-bit
ones would suffice just fine.

Sparc64 and PPC64 are different from ia64 in that the apps truly
run on the processor at full speed, no in some compat logic soldered
onto the cpu like the ia64 x86 support seems to be :-)

X86_64 on the other hand seems to run x86 binaries in a similar
fashion.  I don't know how people currently doing this port intend
to do the useland, but I bet it would benefit from a mostly 32-bit
userland just like sparc64/ppc64 does, both in space and performance.


  reply	other threads:[~2002-12-02  4:16 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-27  7:42 Stephen Rothwell
2002-11-27  7:58 ` David S. Miller
2002-11-27 13:00   ` Stephen Rothwell
2002-11-28  5:27     ` David S. Miller
2002-11-27 18:51   ` Linus Torvalds
2002-11-28  5:34     ` David S. Miller
2002-11-27  8:00 ` David Mosberger
2002-11-27  8:06   ` David S. Miller
2002-11-27  8:29   ` Andi Kleen
2002-11-27  8:46     ` David Mosberger
2002-11-27  9:01       ` Andi Kleen
2002-11-27  9:57       ` David S. Miller
2002-11-27 17:10         ` David Mosberger
2002-11-28  5:29           ` David S. Miller
2002-11-27 12:49     ` Alan Cox
2002-11-30 20:34     ` Ralf Baechle
2002-11-27 17:18 ` Linus Torvalds
2002-11-28  5:22   ` Stephen Rothwell
2002-11-28  5:26     ` David S. Miller
2002-11-29  2:36       ` Stephen Rothwell
2002-12-01 18:54       ` Linus Torvalds
2002-12-02  4:46         ` David S. Miller [this message]
2002-12-02  4:57           ` Stephen Rothwell
2002-12-02  6:17             ` David S. Miller
2002-12-02  7:39           ` Richard Henderson
2002-12-02  7:44             ` David S. Miller
2002-12-02  7:59             ` Ralf Baechle
2002-12-02  8:01               ` David S. Miller
2002-12-04 11:22                 ` Pavel Machek
2002-12-05 21:04                   ` David S. Miller
2002-11-28  5:31   ` David S. Miller
2002-11-29  4:45     ` [PATCH] 32 bit consolidation 1/Many (was: [PATCH] Start of compat32.h (again)) Stephen Rothwell
2002-11-29  4:52       ` [PATCH] 32 bit consolidation 2/Many Stephen Rothwell
     [not found] <Pine.LNX.4.44.0212011047440.12964-100000@home.transmeta.com.suse.lists.linux.kernel>
     [not found] ` <1038804400.4411.4.camel@rth.ninka.net.suse.lists.linux.kernel>
2002-12-02  8:13   ` [PATCH] Start of compat32.h (again) Andi Kleen
2002-12-02  8:28     ` David S. Miller
2002-12-02  9:07       ` Andi Kleen
2002-12-02  9:36         ` Jakub Jelinek
2002-12-02 17:01           ` Mikael Pettersson
2002-12-02 10:16         ` David S. Miller
2002-12-04 11:19           ` Pavel Machek
2002-12-05 21:06             ` David S. Miller
2002-12-05 21:21               ` Pavel Machek
2002-12-05 21:22                 ` David S. Miller
2002-12-05 21:32                   ` Pavel Machek

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=1038804400.4411.4.camel@rth.ninka.net \
    --to=davem@redhat.com \
    --cc=ak@muc.de \
    --cc=anton@samba.org \
    --cc=davidm@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ralf@gnu.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@transmeta.com \
    --cc=willy@debian.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

all inboxes | Powered by JetHome®