linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Paul Wagland <paul@wagland.net>
Cc: linux-kernel@vger.kernel.org, gktnews@gktech.net
Subject: Re: amd64 questions
Date: Wed, 07 Apr 2004 18:15:38 +0200	[thread overview]
Message-ID: <m3isgb69xx.fsf@averell.firstfloor.org> (raw)
In-Reply-To: <1IntE-7wn-39@gated-at.bofh.it> (Paul Wagland's message of "Wed, 07 Apr 2004 17:50:18 +0200")

Paul Wagland <paul@wagland.net> writes:

> On Apr 7, 2004, at 13:29, Andi Kleen wrote:
>
>> A few programs (namely iptables and ipsec tools) need to be used
>> as 64bit programs because the 32bit emulation doesn't work for them.
>> ipchains works though.
>
> I seem to recall reading that the DM based programs also need to be 64
> bit, since their 32 bit stuff was also broken?

That was already fixed, but the fix may not be in mainline yet
[and I think it broke ppc64 too]. But right, DM has problems too.

> The question I have is whether or not this is a kernel bug that should
> be fixed? As I understand the DM case, fixing it so that 32bit works,
> then breaks the 64bit interfaces, requiring re-compiles of the DM
> programs.

It is a subsystem bug really. These subsystems were all designed to
not require emulation, but the designers weren't aware of all the
requirements for this and broke it for AMD64/IA64. Unfortunately the
interfaces were done in a way that it would be very complicated and a
lot of work to write an emulation layer, because they're extremly
emulation unfriendly. Maybe it would be still possible to write an
emulation layer, but easier is it to just use static 64bit executables 
or hacked 32bit executables.

I don't have any plans to write emulation layers for such hopeless
cases on my own, but just declared these subsystems as broken.

The problem is always the long long alignment. AMD64/IA64 have different
alignment for long long than i386. The emulation was originally tested
on some RISC port, where the alignment is the same.

-Andi


       reply	other threads:[~2004-04-07 16:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1Ijzw-4ff-5@gated-at.bofh.it>
     [not found] ` <1Ijzv-4ff-3@gated-at.bofh.it>
     [not found]   ` <1IntE-7wn-39@gated-at.bofh.it>
2004-04-07 16:15     ` Andi Kleen [this message]
2004-04-07 16:49       ` amd64 questions Chris Friesen
2004-04-07 18:08         ` Andi Kleen
2004-04-10 16:54       ` J. Ryan Earl
2004-04-10 18:49         ` Andi Kleen
2004-04-10 19:02           ` Hugo Mills
2004-04-11 11:37             ` Paul Wagland
2004-04-11 11:45               ` Hugo Mills
2004-04-10 20:01           ` J. Ryan Earl
     [not found] <1I8up-46J-3@gated-at.bofh.it>
2004-04-07 11:29 ` Andi Kleen
2004-04-07 15:24   ` Paul Wagland
2004-04-07 17:36   ` Bryan Koschmann - GKT
2004-04-06 23:37 Bryan Koschmann - GKT

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=m3isgb69xx.fsf@averell.firstfloor.org \
    --to=ak@muc.de \
    --cc=gktnews@gktech.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@wagland.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).