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. > https://android.googlesource.com/platform/bionic.git/+/master/libc/include/sys/epoll.h > typedef union epoll_data { > void* ptr; > int fd; > uint32_t u32; > uint64_t u64; > } epoll_data_t; > struct epoll_event { > uint32_t events; > epoll_data_t data; > } > > Kernel UAPI header defined as "include/uapi/linux/eventpoll.h" > struct epoll_event { > __u32 events; > __u64 data; =====>opaque type instead of union epoll_data > } EPOLL_PACKED; > > > Because of this we are landing into some issues as we copy kernel > headers. Will it be going to be addressed? What issues are you having? Exactly what problems are you running in to? Using all of the UAPI headers directly is not a workable solution, there is a lot of definition and cleanup work to do there. Some of the headers are immediately useful, but others, as you note require quite a bit of work to become useful. The underlying issue of a mismatch between userspace expectations and UAPI definitions will get addressed when someone, maybe you, works diligently to enhance the kernel UAPI headers to be generally useful to userspace. 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 possible between the kernel and userspace. -- Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
