Update if.h to match Linux kernel headers?

Update if.h to match Linux kernel headers?

[Carlos O'Donell]

Florian,

Should we be updating if.h to match linux/if.h?

I'm not entirely sure if userspace can make use of these flags, but one
could conceivably write userspace tools and drivers that would.

We don't have a Linux-specific header for this, but I don't think it
matters. Linux ends up being the defacto place where these value are
being defined and then used in other OSs.

Thoughts?

diff --git a/sysdeps/gnu/net/if.h b/sysdeps/gnu/net/if.h
index bbc2094..c56dcac 100644
--- a/sysdeps/gnu/net/if.h
+++ b/sysdeps/gnu/net/if.h
@@ -78,6 +78,12 @@ enum
 # define IFF_AUTOMEDIA IFF_AUTOMEDIA
     IFF_DYNAMIC = 0x8000       /* Dialup device with changing addresses.  */
 # define IFF_DYNAMIC   IFF_DYNAMIC
+    IFF_LOWER_UP = 0x10000     /* Network interface carrier on.  */
+# define IFF_LOWER_UP  IFF_LOWER_UP
+    IFF_DORMANT = 0x20000      /* Network interface dormant.  */
+# define IFF_DORMANT   IFF_DORMANT
+    IFF_ECHO = 0x40000         /* Do not locally echo sent frames.  */
+# define IFF_ECHO      IFF_ECHO
   };
 
 /* The ifaddr structure contains information about one address of an
---

-- 
Cheers,
Carlos.

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

[Joseph Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Andreas Schwab]

Carlos O'Donell <carlos@redhat.com> writes:

> Should we be updating if.h to match linux/if.h?
>
> I'm not entirely sure if userspace can make use of these flags, but one
> could conceivably write userspace tools and drivers that would.

It's a uapi header, thus intented to be used by user-space.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Szabolcs Nagy]

On 17/06/16 10:12, 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.
> 

musl has these for completeness anyway, the
flags can be queried from userspace via
/sys/class/net/<dev>/flags
(i also added IFF_VOLATILE to musl if.h)

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

[Florian Weimer]

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?

Thanks,
Florian

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

[David Miller]

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.

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

[Florian Weimer]

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?

So maybe we should put them into a separate enum block and point to 
struct ifaddrs and getifaddrs?

Thanks,
Florian

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

[Szabolcs Nagy]

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?
> 
> 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.

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

[Florian Weimer]

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