From: Matthew Wilcox <willy@debian.org>
To: Erik Andersen <andersen@codepoet.org>,
Matthew Wilcox <willy@debian.org>,
Alexander Viro <viro@math.psu.edu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] work around duff ABIs
Date: Tue, 22 Oct 2002 14:04:28 +0100 [thread overview]
Message-ID: <20021022140428.B27461@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <20021022044309.GA25172@codepoet.org>; from andersen@codepoet.org on Mon, Oct 21, 2002 at 10:43:10PM -0600
On Mon, Oct 21, 2002 at 10:43:10PM -0600, Erik Andersen wrote:
> I understand the problem very well. Passing 64 bit stuff via
> syscalls is a major pain in the butt. But your patch is not just
> changing hppa and mips -- you are breaking the ABI on x86, arm,
> powerpc, etc, etc. etc where it is currently working. Look very
> closely at your patch. See those endianness ifdefs? You are
> adding endianness specific ifdefs into pread, truncate, and
> ftruncate to switch the argument order. User space is already
> doing that too. At no time on any architecture is the low stuff
> passed into arg3. Ergo, your patch is going to break userspace
> where pread and pread64 are now working correctly....
Nope. Some architectures _do not_ pad 64-bit arguments, others _do_.
On ARM/x86, we currently do use arg3 for the low part of the argument,
but on PPC we use it for the high part because of this sexswapping
crap being done in userspace.
> If you want to change the kernel to passing eliminate 64 bit
> stuff via syscalls, and instead pass pairs of 32bit entities --
> I'm all for that as that would make explicit what user space is
> doing anyways. But don't break binary compatibility for no
> reason. Why make both user-space _and_ kernel space add ifdefs
> for endianness? Make arg3 _always_ contain the hi-bits.
I'd love to move to that model. But I suspect we need a consensus to
_never_ pass 64-bit quantities across the syscall boundary, and we
aren't going to get it. So we're going to add more crap every time
someone adds a loff_t ;-(
--
Revolutions do not require corporate support.
next prev parent reply other threads:[~2002-10-22 12:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-20 4:31 [PATCH] work around duff ABIs Matthew Wilcox
2002-10-20 4:45 ` John Levon
2002-10-20 4:51 ` Erik Andersen
2002-10-20 12:51 ` Matthew Wilcox
2002-10-21 12:14 ` Alan Cox
2002-10-22 4:43 ` Erik Andersen
2002-10-22 13:04 ` Matthew Wilcox [this message]
2002-10-21 12:13 ` Alan Cox
2002-10-21 13:48 ` Matthew Wilcox
2002-10-21 16:26 ` Alan Cox
2002-11-04 5:10 ` Richard Henderson
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=20021022140428.B27461@parcelfarce.linux.theplanet.co.uk \
--to=willy@debian.org \
--cc=andersen@codepoet.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/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