Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
	Davide Libenzi <davidel@xmailserver.org>,
	linux-mips@linux-mips.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@openvz.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ulrich Drepper <drepper@redhat.com>
Subject: Re: -mm merge plans for 2.6.21
Date: Sat, 10 Feb 2007 21:34:47 +0000	[thread overview]
Message-ID: <20070210213447.GB9116@linux-mips.org> (raw)
In-Reply-To: <1171103527.29713.228.camel@pmac.infradead.org>

On Sat, Feb 10, 2007 at 10:32:07AM +0000, David Woodhouse wrote:

> On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote:
> > Which remembers me that I think that MIPS is using the non-compat version
> > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat
> > syscall for some reason. Dunno. 
> 
> It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree
> there there's 32 bits of padding between the fields of this structure:
> 
> struct epoll_event {
>         __u32 events;
>         __u64 data;
> };
> 
> I suspect it's a fairly safe bet that N32 userspace agrees; if the O32
> ABI is different then it would need the compat syscall.

That is correct - and apparently for all ABIs because I wasn't able to find
a compat_sys_epoll_pwait at all.

Unfortunately struct epoll_event contains a gap so it bets on identical
padding rules between native and compat ABI and anyway, padding is wasted
space so the struct members should have been swapped when this structure
was created.  Oh well, too late.

  Ralf

  reply	other threads:[~2007-02-11  2:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070208150710.1324f6b4.akpm@linux-foundation.org>
     [not found] ` <1171042535.29713.96.camel@pmac.infradead.org>
     [not found]   ` <20070209134516.2367a7aa.akpm@linux-foundation.org>
     [not found]     ` <1171058342.29713.136.camel@pmac.infradead.org>
     [not found]       ` <Pine.LNX.4.64.0702091442230.2786@alien.or.mcafeemobile.com>
2007-02-10 10:22         ` -mm merge plans for 2.6.21 Heiko Carstens
2007-02-10 10:32           ` David Woodhouse
2007-02-10 21:34             ` Ralf Baechle [this message]
2007-02-11  4:53               ` Davide Libenzi
2007-02-11 15:33               ` David Woodhouse
2007-02-11 16:09                 ` Ralf Baechle
2007-02-11 16:14               ` Heiko Carstens
2007-02-11 16:34                 ` Davide Libenzi
2007-02-11 18:01                 ` Ralf Baechle
2007-02-10 21:05           ` Ralf Baechle
2007-02-11 10:37             ` Andi Kleen

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=20070210213447.GB9116@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=adobriyan@openvz.org \
    --cc=akpm@linux-foundation.org \
    --cc=davidel@xmailserver.org \
    --cc=drepper@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    /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