On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger <vapier@xxxxxxxxxx> wrote: > On Wednesday 16 January 2013 22:15:38 David Miller wrote: >> From: Carlos O'Donell <carlos@xxxxxxxxxxxxxxxx> >> Date: Wed, 16 Jan 2013 21:15:03 -0500 >> >> > +/* If a glibc-based userspace has already included in.h, then we will >> > not + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq. >> > The + * ABI used by the kernel and by glibc match exactly. Neither the >> > kernel + * nor glibc should break this ABI without coordination. >> > + */ >> > +#ifndef _NETINET_IN_H >> > + >> >> I think we should shoot for a non-glibc-centric solution. >> >> I can't imagine that other libc's won't have the same exact problem >> with their netinet/in.h conflicting with the kernel's, redefining >> structures like in6_addr, that we'd want to provide a protection >> scheme for here as well. > > yes, the kernel's use of __GLIBC__ in exported headers has already caused > problems in the past. fortunately, it's been reduced down to just one case > now (stat.h). let's not balloon it back up. > -mike I also see coda.h has grown a __GLIBC__ usage. In the next revision of the patch I created a single libc-compat.h header which encompasses the logic for any libc that wants to coordinate with the kernel headers. It's simple enough to move all of the __GLIBC__ uses into libc-compat.h, then you control userspace libc coordination from one file. Cheers, Carlos. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list