[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3634139.5BAXH7nXYb@wuerfel>
Date: Sun, 04 Sep 2011 23:41:03 +0200
From: Arnd Bergmann <arnd@...db.de>
To: "H.J. Lu" <hjl.tools@...il.com>
Cc: "H. Peter Anvin" <hpa@...or.com>, Valdis.Kletnieks@...edu,
Linus Torvalds <torvalds@...ux-foundation.org>,
Christoph Hellwig <hch@...radead.org>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Richard Kuo <rkuo@...eaurora.org>,
Mark Salter <msalter@...hat.com>,
Jonas Bonn <jonas@...thpole.se>,
Tobias Klauser <tklauser@...tanz.ch>
Subject: Re: RFD: x32 ABI system call numbers
On Sunday 04 September 2011 14:25:53 H.J. Lu wrote:
> >> >> #define __NR_x32_recvfrom
> >> >> #define __NR_x32_sendmsg
> >> >> #define __NR_x32_recvmsg
> >> >> #define __NR_x32_recvmmsg
> >> >> #define __NR_x32_sendmmsg
> >> >
> >> > These today use the MSG_CMSG_COMPAT flag to distinguish native and compat
> >> > calls. Do you plan to have another flag here to handle cmsg time values?
> >>
> >> I am using x86-32 calls for them.
> >>
> >> > What about things like mq_{get,set}attr, quotactl and semtimedop?
> >> >
> >>
> >> I am using 64bit system calls for x32.
> >
> > But isn't that broken? These all pass u64 or time_t values at some point.
> >
>
> time_t isn't a problem since time_t/timeval/timespec are identical for
> x32 and x86-64. As for u64, I added NATIVE_LONG_TYPE, which is
> defined as long long for x32, and use it instead of long in types for
> 64bit system calls.
Sorry, I misread you as saying you use the compat syscalls for these.
If you use the native 64 bit syscalls, you have the opposite problem:
Some network protocols (e.g. netlink or rxrpc) use other data structures
that require conversion, e.g. 'long' members that x32 will get wrong.
For quotactl I guess you are right, using the 64 bit call instead
of the x86_32 call will just work on x32 like they do on other compat
architectures. The same should be true for semtimedop, I had misinterpreted
that one thinking that you would still need to convert struct sembuf
(you would need that on another architecture which uses 32 bit struct
alignment in one ABI but the other).
For mq_{get,set}attr, I think you will either have to use the 32 bit
call or conditionally define struct mq_attr to contain 'long long'
members.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists