Re: epoll handling in the alpha port

2007-02-01 Thread Mike Frysinger
On Friday 02 February 2007, Willy Tarreau wrote: > I think it would be reasonable to use the NR_epoll* names first, and to > declare NR_sys_epoll* aliases which will point to NR_epoll*. You would > then add a comment with the date of the change, stating that you keep > them just in case there are s

Re: epoll handling in the alpha port

2007-02-01 Thread Willy Tarreau
On Fri, Feb 02, 2007 at 12:19:35AM -0500, Mike Frysinger wrote: > On Friday 02 February 2007, Andrew Morton wrote: > > It might be to late to fix this - we risk breaking userspace which worked > > around it. > > we'd be breaking userspace API, but not ABI ... and the largest consumers out > there

Re: epoll handling in the alpha port

2007-02-01 Thread Mike Frysinger
On Friday 02 February 2007, Andrew Morton wrote: > It might be to late to fix this - we risk breaking userspace which worked > around it. we'd be breaking userspace API, but not ABI ... and the largest consumers out there (glibc/uclibc) have not been accounting for this, so we wouldnt be breakin

Re: epoll handling in the alpha port

2007-02-01 Thread Andrew Morton
On Thu, 1 Feb 2007 15:20:45 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > the alpha linux port differs from all others when it comes to the epoll > functions in that it uses '__NR_sys_epoll_XXX' instead of '__NR_epoll_XXX' in > the asm/unistd.h header ... the trouble with this is that glibc

epoll handling in the alpha port

2007-02-01 Thread Mike Frysinger
the alpha linux port differs from all others when it comes to the epoll functions in that it uses '__NR_sys_epoll_XXX' instead of '__NR_epoll_XXX' in the asm/unistd.h header ... the trouble with this is that glibc maps the function name directly to an __NR_ define, so when it maps like 'epoll_c