Re: -mm merge plans for 2.6.21

[Davide Libenzi]

On Sun, 11 Feb 2007, Heiko Carstens wrote:

> On Sat, Feb 10, 2007 at 09:34:47PM +0000, Ralf Baechle wrote:
> > 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.
> 
> Hmm.. so you don't need to do some fancy compat conversion for the sigset_t
> that gets passed? Why is that? I don't get it...

The compat_sys_epoll_pwait function has two sources of compat. One is the 
sigset_t and the other one is the struct epoll_event. The sigset_t compat 
is always needed, while the struct epoll_event may be needed. The code of 
(upcoming) compat_sys_epoll_pwait takes care of both, with a smart 
compile-time check to wire sys_epoll_wait or compat_sys_epoll_wait, 
depending on the need of the struct epoll_event compat handling.
So yes, compat_sys_epoll_pwait is needed.



- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/