From: Andi Kleen <ak@suse.de>
To: hadi@cyberus.ca
Cc: jgarzik@pobox.com, greearb@candelatech.com, amir.noam@intel.com,
bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com
Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces
Date: Mon, 12 Jan 2004 16:04:46 +0100 [thread overview]
Message-ID: <20040112160446.691e187e.ak@suse.de> (raw)
In-Reply-To: <1073915461.1118.342.camel@jzny.localdomain>
On 12 Jan 2004 08:51:02 -0500
jamal <hadi@cyberus.ca> wrote:
> Andi,
> Can you point to specifics that break 64 bit emulation so we can avoid
> them?
> I have to admit the pf_key interaction is relatively unorthrodox but
> looked fine.
Ok, here are the full rules:
Standards:
long/void * are disallowed
use [su]{16,32,64} instead
Non obvious problems specific to IA64 and x86-64 (they don't happen on sparc64/ppc64,
that is why they were often not catched earlier):
When you use [su]64:
make sure the data element is explicitely padded to be on a 8 byte boundary
in the structure. The reason is that alignof(u64) on i386 is 4 but 8 on ia64/x86-64
and the structure layout could change.
also when you use 64bit types make sure the complete structure is padded to 8 bytes.
The x86-64 ABI pads any data structure to the alignof() of its biggest member
to get good alignment for arrays. This is what broke PF_KEY - it is missing this
padding and the structure layout ends up differently with nested structures.
> What are the things you will perform surgery on?
I'm not sure I will because it is too ugly. Or at least I haven't found a nice elegant
way for it yet. Currently you just cannot use ipsec from 32bit executables, you have to use
64bit.
-Andi
next prev parent reply other threads:[~2004-01-12 15:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E6F7D288B394A64585E67497E5126BA601F991D1@hasmsx403.iil.intel.com>
2004-01-11 14:28 ` [bonding] Add basic support for dynamic configuration of bond interfaces Amir Noam
2004-01-11 18:30 ` jamal
2004-01-11 19:39 ` Jeff Garzik
2004-01-11 21:34 ` Ben Greear
2004-01-11 21:59 ` Jeff Garzik
2004-01-11 22:50 ` jamal
2004-01-11 22:51 ` Ben Greear
2004-01-12 0:13 ` Jason Lunz
2004-01-13 2:34 ` Jeff Garzik
2004-01-12 12:38 ` Andi Kleen
2004-01-12 13:51 ` jamal
2004-01-12 15:04 ` Andi Kleen [this message]
2004-01-13 12:28 ` jamal
2004-01-13 12:39 ` Andi Kleen
[not found] <E6F7D288B394A64585E67497E5126BA601F991D3@hasmsx403.iil.intel.com>
2004-01-14 15:00 ` Amir Noam
2004-01-08 16:19 Amir Noam
2004-01-11 1:34 ` Jeff Garzik
2004-01-12 17:23 ` Ben Greear
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=20040112160446.691e187e.ak@suse.de \
--to=ak@suse.de \
--cc=amir.noam@intel.com \
--cc=bonding-devel@lists.sourceforge.net \
--cc=greearb@candelatech.com \
--cc=hadi@cyberus.ca \
--cc=jgarzik@pobox.com \
--cc=netdev@oss.sgi.com \
/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.