Re: Update if.h to match Linux kernel headers?

[Florian Weimer <fweimer at redhat dot com>]

On 06/23/2016 06:21 PM, Szabolcs Nagy wrote:
> On 23/06/16 17:06, Florian Weimer wrote:
> > On 06/23/2016 05:57 PM, David Miller wrote:
> > > From: Florian Weimer <fweimer@redhat.com>
> > > Date: Thu, 23 Jun 2016 17:10:54 +0200
> > >
> > > > On 06/17/2016 11:12 AM, Joseph Myers wrote:
> > > > > On Thu, 16 Jun 2016, Carlos O'Donell wrote:
> > > > >
> > > > > > I'm not entirely sure if userspace can make use of these flags, but
> > > > > > one
> > > > > > could conceivably write userspace tools and drivers that would.
> > > > >
> > > > > In <https://sourceware.org/ml/libc-alpha/2014-06/msg00413.html> I
> > > > > noted
> > > > > that I presumed the exclusion of IFF_* values not fitting in a "short"
> > > > > flags field was deliberate.
> > > >
> > > > Can you elaborate way?  Do you fear that we might end up with an ABI
> > > > change if the enum promotes to int, not short?  But doesn't do it that
> > > > already, due to the value IFF_DYNAMIC = 0x8000?
> > >
> > > Because ifr_flags in struct ifreq is 16-bit.
> >
> > But these flags are also used for ifr_flags?

Sorry, I meant ‘ifa_flags’, an important difference.  Sorry.

> > So maybe we should put them into a separate enum block and point to struct ifaddrs and getifaddrs?
>
> i don't see how the enum matters.

I meant that for documentation purposes.

> and ifr_flags is not the only way to use these
> so that should not limit the definitions either.

Yes, ifa_flags uses them (but it's defined in another header files), 
which is why I suggested adding a comment explaining the difference.

Thanks,
Florian