This is the mail archive of the
mailing list for the glibc project.
Re: Update if.h to match Linux kernel headers?
- From: Florian Weimer <fweimer at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, David Miller <davem at davemloft dot net>
- Cc: nd at arm dot com, joseph at codesourcery dot com, carlos at redhat dot com, libc-alpha at sourceware dot org
- Date: Thu, 23 Jun 2016 18:27:41 +0200
- Subject: Re: Update if.h to match Linux kernel headers?
- Authentication-results: sourceware.org; auth=none
- References: <acfcff1c-1da0-d12b-d300-42e602d17c84 at redhat dot com> <alpine dot DEB dot 2 dot 20 dot 1606170911251 dot 14216 at digraph dot polyomino dot org dot uk> <28221c3a-ba59-8112-0a4e-ccfe83a057dd at redhat dot com> <20160623 dot 115746 dot 1531549845529328362 dot davem at davemloft dot net> <785ed716-1a19-502a-77e6-e36991420a10 at redhat dot com> <576C0C78 dot 2060001 at arm 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 <firstname.lastname@example.org>
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
could conceivably write userspace tools and drivers that would.
In <https://sourceware.org/ml/libc-alpha/2014-06/msg00413.html> I
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.