This is the mail archive of the
mailing list for the glibc project.
Re: Update if.h to match Linux kernel headers?
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Florian Weimer <fweimer at redhat 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 17:21:12 +0100
- Subject: Re: Update if.h to match Linux kernel headers?
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- 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>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 23/06/16 17:06, Florian Weimer wrote:
> On 06/23/2016 05:57 PM, David Miller wrote:
>> From: Florian Weimer <email@example.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
>>>>> 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?
> 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.
and ifr_flags is not the only way to use these
so that should not limit the definitions either.