block layer sg, bsg
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · David S. Miller
Or use a more portable well-defined type which does not change size nor layout between 32-bit and 64-bit environments.
That is usually a mistake. People get the more subtle issues like long long handling wrong, and then it is impossible to fix it anymore in a compat layer (examples are ipsec and iptables, which cannot be emulated on x86-64 because of that)
So please never pass any structures with read/write/netlink.
Thank you.
-Andi
Quoted 11 lines · Andi Kleen
Quoted 3 lines · David S. Miller
Or use a more portable well-defined type which does not change size nor layout between 32-bit and 64-bit environments.
That is usually a mistake. People get the more subtle issues like long long handling wrong, and then it is impossible to fix it anymore in a compat layer (examples are ipsec and iptables, which cannot be emulated on x86-64 because of that)
So please never pass any structures with read/write/netlink.
Which basically brings us back to SG_IO, or (alternatively) SG_IO_WRITE and SG_IO_READ ioctls. I doubt that is really worth it, however. There's just not a huge need to do it.
Signature · 1 line
Jens Axboe
Quoted 1 line · Andi Kleen
So please never pass any structures with read/write/netlink.
Sorry... This is pretty much a given IMO.
Jeff
Quoted 4 lines · On Wed, 4 Aug 2004 15:18:50 -0400 Jeff Garzik <[email protected]> wrote:
Quoted 1 line · Andi Kleen
So please never pass any structures with read/write/netlink.
Sorry... This is pretty much a given IMO.
Yes, netlink would be a nop if we gave in to Andi's reccomendation :-)
Quoted 10 lines · David S. Miller
Quoted 4 lines · On Wed, 4 Aug 2004 15:18:50 -0400 Jeff Garzik <[email protected]> wrote:
Quoted 1 line · Andi Kleen
So please never pass any structures with read/write/netlink.
Sorry... This is pretty much a given IMO.
Yes, netlink would be a nop if we gave in to Andi's reccomendation :-)
Well, 32bit ipsec on x86-64/ia64 is a NOP because of that.
Alternatively for me it would be enough if you never use long long in such data structures. That is what broke ipsec. And it's pretty much unfixable because netlink is so adverse to emulation layers.
Longer term adding a presentation layer to netlink will be likely a good idea. That's also needed for the cluster netlink stuff some people are talking about.
-Andi
Quoted 2 lines · On 5 Aug 2004 01:21:16 +0200 Andi Kleen <[email protected]> wrote:
And it's pretty much unfixable because netlink is so adverse to emulation layers.
It is doable with is_compat_task() but you were against that. That's unfortunate, since is_compat_task() provides a neat solution for things like the USB device fs async stuff (ie. so 32-bit libusb would work on 64-bit systems)
In article <[email protected]> (at 5 Aug 2004 01:21:16 +0200,Thu, 5 Aug 2004 01:21:16 +0200), Andi Kleen <[email protected]> says:
Quoted 5 lines · David S. Miller
Quoted 4 lines
Quoted 1 line · On Wed, 4 Aug 2004 15:18:50 -0400 Jeff Garzik <[email protected]> wrote:
On Wed, Aug 04, 2004 at 07:28:04PM +0200, Andi Kleen wrote:
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
So please never pass any structures with read/write/netlink.
Sorry... This is pretty much a given IMO.
Yes, netlink would be a nop if we gave in to Andi's reccomendation :-)
Well, 32bit ipsec on x86-64/ia64 is a NOP because of that.
Hmm, I don't get the point.
What part (or which structore) is broken?
--yoshfuji
Quoted 4 lines · On Wed, 04 Aug 2004 16:51:13 -0700 (PDT) YOSHIFUJI Hideaki / $B5HF#1QL@(B…
Quoted 1 line
Well, 32bit ipsec on x86-64/ia64 is a NOP because of that.
Hmm, I don't get the point.
What part (or which structore) is broken?
On x86-64 and ia64 they have a large issue because the ia32 emulation layer has to handle the fact that "long long" types do not require 8-byte alignment, whereas 64-bit natively they do.
So all things going over netlink that use u64 or similar have potential structure layout issues due to this difference.
Hi Dave,
Quoted 5 lines · David S. Miller
On Wed, 04 Aug 2004 16:51:13 -0700 (PDT)
Quoted 2 lines · YOSHIFUJI Hideaki / $B5HF#1QL@(B <[email protected]> wrote:
Quoted 1 line
Well, 32bit ipsec on x86-64/ia64 is a NOP because of that.
Quoted 7 lines
Quoted 2 lines
Hmm, I don't get the point.
What part (or which structore) is broken?On x86-64 and ia64 they have a large issue because the ia32 emulation layer has to handle the fact that "long long" types do not require 8-byte alignment, whereas 64-bit natively they do.
I'm making heavy use of struct read/writes in the cluster snapshot block device, so I need to get this sorted out.
Somewhere I got the idea that if a structure is declared with attribute PACKED, gcc will generate alignment-independent code (e.g., access each field byte by byte) on alignment-restricted architectures. So if what I imagine about gcc is true, what issues remain? These structs have to be declared packed anyway and with fixed field sizes, or the layout will vary across architectures.
Regards,
Daniel
Quoted 6 lines
Somewhere I got the idea that if a structure is declared with attribute PACKED, gcc will generate alignment-independent code (e.g., access each field byte by byte) on alignment-restricted architectures. So if what I imagine about gcc is true, what issues remain? These structs have to be declared packed anyway and with fixed field sizes, or the layout will vary across architectures.
With packed things should be fine for x86-64/i386. However it may generate bad code for other architectures.
-Andi
Quoted 9 lines · Andi Kleen
Quoted 6 lines
Somewhere I got the idea that if a structure is declared with attribute PACKED, gcc will generate alignment-independent code (e.g., access each field byte by byte) on alignment-restricted architectures. So if what I imagine about gcc is true, what issues remain? These structs have to be declared packed anyway and with fixed field sizes, or the layout will vary across architectures.
With packed things should be fine for x86-64/i386. However it may generate bad code for other architectures.
That's the question. From talking to gcc developers in the former Cygnus office, it's thought that alignment-restricted architectures are supposed to do bytewise access (or equivalent) to PACKED fields, but nobody was sure if every architecture implements this, or even if it's the formally defined behavior for PACKED. That's a subset of GCC developers of course.
As far as I can see, if PACKED doesn't work this way on all architectures then it's broken and needs to be fixed.
Regards,
Daniel
Quoted 4 lines
Quoted 1 line
Well, 32bit ipsec on x86-64/ia64 is a NOP because of that.
Hmm, I don't get the point.
What part (or which structore) is broken?
xfrm_usersa_info due to inclusion of xfrm_lifetime_cfg/xfrm_lifetime_cur The xfrm layer uses it like an array, but they have different sizes on x86-64 and i386.
-Andi
In article <[email protected]> (at 5 Aug 2004 13:49:17 +0200,Thu, 5 Aug 2004 13:49:17 +0200), Andi Kleen <[email protected]> says:
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Well, 32bit ipsec on x86-64/ia64 is a NOP because of that.
Hmm, I don't get the point.
What part (or which structore) is broken?
xfrm_usersa_infodue to inclusion of xfrm_lifetime_cfg/xfrm_lifetime_cur The xfrm layer uses it like an array, but they have different sizes on x86-64 and i386.
Thanks for clarifications, David and Andi.
Okay, I now recognize that the difference of layouts, one on 32bit mode and one on 64bit mode is the problem.
I'd suggest changing XFRM_MSG_xxx things to 64bit-aware structures, whose layouts do not change between 64bit mode and 32bit mode. Of course, they will come with backward compatibility stuff. If you don't mind this, I'd like to take care of this.
Thanks.
--yoshfuji
Quoted 4 lines · On Thu, 05 Aug 2004 20:46:37 -0700 (PDT) YOSHIFUJI Hideaki / $B5HF#1QL@(B…
I'd suggest changing
XFRM_MSG_xxxthings to 64bit-aware structures, whose layouts do not change between 64bit mode and 32bit mode. Of course, they will come with backward compatibility stuff. If you don't mind this, I'd like to take care of this.
I think other tasks have much higher priority, especially when a workaround exists for this problem, namely building the native 64-bit version of the tool.
Quoted 11 lines · David S. Miller
Quoted 4 lines · On Thu, 05 Aug 2004 20:46:37 -0700 (PDT) YOSHIFUJI Hideaki / $B5HF#1QL@(B…
I'd suggest changing
XFRM_MSG_xxxthings to 64bit-aware structures, whose layouts do not change between 64bit mode and 32bit mode. Of course, they will come with backward compatibility stuff. If you don't mind this, I'd like to take care of this.I think other tasks have much higher priority, especially when a workaround exists for this problem, namely building the native 64-bit version of the tool.
As long as it runs on sparc64 it's not critical I guess :|
People who can easily build 64bit programs normally don't need any 32bit userland.
-Andi
Quoted 2 lines · On 6 Aug 2004 15:20:25 +0200 Andi Kleen <[email protected]> wrote:
People who can easily build 64bit programs normally don't need any 32bit userland.
This isn't even an issue of whether some complex 64-bit library other than libc is present. If you have a 64-bit userland compiler and libc, you can ship the 64-bit version of the ipsec tools. Heck they don't even need something like readline or stuff like that :-)
Quoted 4 lines
I'd suggest changing
XFRM_MSG_xxxthings to 64bit-aware structures, whose layouts do not change between 64bit mode and 32bit mode. Of course, they will come with backward compatibility stuff. If you don't mind this, I'd like to take care of this.
If you could take care of it it would be great. Althought I'm not sure how to do it without breaking backwards compatibility.
-Andi