[davem@redhat.com: Re: [PATCH] Start of compat32.h (again)]

[undefine@aramin.one.pl]

hm..
po przemysleniu...
jest wogole sens w takim razie pakowac sie w kod 64 bit na sparcach i
ppc? moze po prostu dalej rozwijac kod 32 bitowy...

----- Forwarded message from "David S. Miller" <davem w redhat.com> -----

Delivered-To: undefine w aramin.one.pl
X-Authentication-Warning: rth.ninka.net: davem set sender to davem w redhat.com using -f
Subject: Re: [PATCH] Start of compat32.h (again)
From: "David S. Miller" <davem w redhat.com>
To: Linus Torvalds <torvalds w transmeta.com>
Cc: sfr w canb.auug.org.au, linux-kernel w vger.kernel.org,
	anton w samba.org, ak w muc.de, davidm w hpl.hp.com,
	schwidefsky w de.ibm.com, ralf w gnu.org, willy w debian.org
In-Reply-To: <Pine.LNX.4.44.0212011047440.12964-100000 w home.transmeta.com>
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date:	01 Dec 2002 20:46:40 -0800
Precedence: bulk
X-Mailing-List:	linux-kernel w vger.kernel.org

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo w vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

----- End forwarded message -----