Re: opaque types instead of union epoll_data

2017-03-08 Thread Greg KH
On Wed, Mar 08, 2017 at 12:34:07PM -0500, Carlos O'Donell wrote: > On 03/07/2017 12:59 PM, Greg KH wrote: > > On Tue, Mar 07, 2017 at 09:33:57AM -0500, Carlos O'Donell wrote: > >> I don't know anyone else who is working on this problem. Though I > >> have a vested interested in it as a glibc

Re: opaque types instead of union epoll_data

2017-03-08 Thread Greg KH
On Wed, Mar 08, 2017 at 12:34:07PM -0500, Carlos O'Donell wrote: > On 03/07/2017 12:59 PM, Greg KH wrote: > > On Tue, Mar 07, 2017 at 09:33:57AM -0500, Carlos O'Donell wrote: > >> I don't know anyone else who is working on this problem. Though I > >> have a vested interested in it as a glibc

Re: opaque types instead of union epoll_data

2017-03-08 Thread Carlos O'Donell
On 03/07/2017 12:59 PM, Greg KH wrote: > On Tue, Mar 07, 2017 at 09:33:57AM -0500, Carlos O'Donell wrote: >> I don't know anyone else who is working on this problem. Though I >> have a vested interested in it as a glibc maintainer, since it would >> be nice to avoid duplicate headers where

Re: opaque types instead of union epoll_data

2017-03-08 Thread Carlos O'Donell
On 03/07/2017 12:59 PM, Greg KH wrote: > On Tue, Mar 07, 2017 at 09:33:57AM -0500, Carlos O'Donell wrote: >> I don't know anyone else who is working on this problem. Though I >> have a vested interested in it as a glibc maintainer, since it would >> be nice to avoid duplicate headers where

Re: opaque types instead of union epoll_data

2017-03-07 Thread Greg KH
On Tue, Mar 07, 2017 at 09:33:57AM -0500, Carlos O'Donell wrote: > On 03/07/2017 07:31 AM, Sodagudi Prasad wrote: > > uapi structs epoll_data are more opaque than user space expects. > > kernel have defined as __u64 instead of the union epoll_data. Because > > of this libc have redefined struct

Re: opaque types instead of union epoll_data

2017-03-07 Thread Greg KH
On Tue, Mar 07, 2017 at 09:33:57AM -0500, Carlos O'Donell wrote: > On 03/07/2017 07:31 AM, Sodagudi Prasad wrote: > > uapi structs epoll_data are more opaque than user space expects. > > kernel have defined as __u64 instead of the union epoll_data. Because > > of this libc have redefined struct

Re: opaque types instead of union epoll_data

2017-03-07 Thread Carlos O'Donell
On 03/07/2017 07:31 AM, Sodagudi Prasad wrote: > uapi structs epoll_data are more opaque than user space expects. > kernel have defined as __u64 instead of the union epoll_data. Because > of this libc have redefined struct epoll_event with union data > member. We do the same in glibc. >

Re: opaque types instead of union epoll_data

2017-03-07 Thread Carlos O'Donell
On 03/07/2017 07:31 AM, Sodagudi Prasad wrote: > uapi structs epoll_data are more opaque than user space expects. > kernel have defined as __u64 instead of the union epoll_data. Because > of this libc have redefined struct epoll_event with union data > member. We do the same in glibc. >

opaque types instead of union epoll_data

2017-03-07 Thread Sodagudi Prasad
Hi All, uapi structs epoll_data are more opaque than user space expects. kernel have defined as __u64 instead of the union epoll_data. Because of this libc have redefined struct epoll_event with union data member.

opaque types instead of union epoll_data

2017-03-07 Thread Sodagudi Prasad
Hi All, uapi structs epoll_data are more opaque than user space expects. kernel have defined as __u64 instead of the union epoll_data. Because of this libc have redefined struct epoll_event with union data member.