private netdev flags into UAPI?

not sure if this has been brought up before, but I realized that the 
private IFF_yyy netdevice flags which weren't exposed to user space so 
far have been moved to include/uapi/linux/if.h, isn't that wrong?

Or.

/* Private (from user) interface flags (netdevice->priv_flags). */
#define IFF_802_1Q_VLAN 0x1             /* 802.1Q VLAN device.          */
#define IFF_EBRIDGE     0x2             /* Ethernet bridging device.    */
[...]                                  * change when it's running */

Or Gerlitz [off-list ref] wrote:

not sure if this has been brought up before, but I realized that the private
IFF_yyy netdevice flags which weren't exposed to user space so far have been
moved to include/uapi/linux/if.h, isn't that wrong?

They were exposed to userspace already.  On my Fedora 16 test box, I see:

	[root@andromeda ~]# grep -r IFF_EBRIDGE /usr/include/linux
	/usr/include/linux/if.h:#define IFF_EBRIDGE     0x2             /* Ethernet bridging device.    */

which is from:

	kernel-headers-3.3.6-3.fc16.x86_64

which was built before UAPI proper started going in:

	[root@andromeda ~]# rpm -qfi /usr/include/linux/if.h | grep "Build Date"
	Build Date  : Wed 16 May 2012 23:05:59 BST

Looking at commit 607ca46e97a1b6594b29647d98a32d545c24bdff, I see:

	--------------------------- include/uapi/linux/if.h ---------------------------
	similarity index 100%
	rename from include/linux/if.h
	rename to include/uapi/linux/if.h

so my script just moved it without alteration.

David

On Mon, Nov 26, 2012 at 11:22 AM, David Howells [off-list ref] wrote:

They were exposed to userspace already

So the script carries the bug into a new directory... why? AFAIK,
intentionally there's no way to read private flags from user space, so
what's the point in defining them there?

Or.

Or Gerlitz [off-list ref] wrote:

On Mon, Nov 26, 2012 at 11:22 AM, David Howells [off-list ref] wrote:

quoted

They were exposed to userspace already

So the script carries the bug into a new directory... why? AFAIK,
intentionally there's no way to read private flags from user space, so
what's the point in defining them there?

How should the script know what's private and what's not?  By the
encapsulation of code inside __KERNEL__ blocks.  In their absence, everything
is assumed to be public - given it is already part of the UAPI.  I don't know
that the code is private rather than the comment is wrong.

David

On 27/11/2012 04:03, David Howells wrote:

Or Gerlitz [off-list ref] wrote:

quoted

On Mon, Nov 26, 2012 at 11:22 AM, David Howells [off-list ref] wrote:

quoted

They were exposed to userspace already

So the script carries the bug into a new directory... why? AFAIK,
intentionally there's no way to read private flags from user space, so
what's the point in defining them there?

How should the script know what's private and what's not?  By the
encapsulation of code inside __KERNEL__ blocks.  In their absence, everything
is assumed to be public - given it is already part of the UAPI.  I don't know
that the code is private rather than the comment is wrong.

makes sense, but I have pointed on a bug in the final result, so this 
way or another, the fact that the bug
existed before doesn't mean we should carry it over.

Or.