[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070210213447.GB9116@linux-mips.org>
Date: Sat, 10 Feb 2007 21:34:47 +0000
From: Ralf Baechle <ralf@...ux-mips.org>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Heiko Carstens <heiko.carstens@...ibm.com>,
Davide Libenzi <davidel@...ilserver.org>,
linux-mips@...ux-mips.org,
Andrew Morton <akpm@...ux-foundation.org>,
Alexey Dobriyan <adobriyan@...nvz.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ulrich Drepper <drepper@...hat.com>
Subject: Re: -mm merge plans for 2.6.21
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
-
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