Skip to contentSkip to conversation

net: expose vlan structure to user space

PATCH David Acker 2 participants 3 messages Apr 14, 2006 1 message not in the archive

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

David Acker

author
#1 lore raw
Quoted 18 lines · David Acker

From Dave Acker <[email protected]>

The purpose is to allow a user space program to use the vlan_ethhdr structure when directly handling 802.1Q packets. This can be done by using a raw socket like:
int s = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
This socket should see VLAN packets from the base interface unchanged (i.e. vlan tag still in packet).
Currently other user space programs that understand VLANs seem to all create their own definitions for this structure.
This patch does NOT expose the defines related to the sizes of VLAN packets and their fields; it only exposes the vlan_ethhdr structure. It was determined that these sizes are not useful since the packet could be as large the MTU of the underlying physical network. Also, you can have nested VLAN headers such that the actual data offset is greater than the size of the vlan_ethhdr structure.
-Dave Acker

Hello folks. Although some conversation appeared on earlier postings of this patch, I though I would reply here since the post I am replying to here gets the diff format right (from the top level instead of deep in the source). Last I heard:

Quoted 2 lines · David S. Miller

I think this really belongs in a portable header file in glibc somewhere.

David, while I can try to work with the glibc folks, I don't understand how this patch would be different from what if_ether.h exposes to user space today. Why is one appropriate and the other not? I am not trying to be a pain; I am just trying to understand the rationale so that I can explain it to others.

Thanks,
Dave Acker

maintainer
#2 lore raw

From: David Acker <[email protected]>
Date: Fri, 14 Apr 2006 09:15:54 -0400

Quoted 9 lines
Quoted 2 lines · David S. Miller

I think this really belongs in a portable header file in glibc somewhere.

David, while I can try to work with the glibc folks, I don't understand how this patch would be different from what if_ether.h exposes to user space today. Why is one appropriate and the other not? I am not trying to be a pain; I am just trying to understand the rationale so that I can explain it to others.

Doing stupid things in the past does not equate to being a reason to keep doing so in the future.

author
#3 lore raw
Quoted 5 lines · David S. Miller

From: David Acker <[email protected]>
Date: Fri, 14 Apr 2006 09:15:54 -0400

Quoted 1 line

David S. Miller wrote:

Quoted 10 lines
Quoted 4 lines
Quoted 2 lines

I think this really belongs in a portable header file in glibc somewhere.

David, while I can try to work with the glibc folks, I don't understand how this patch would be different from what if_ether.h exposes to user space today. Why is one appropriate and the other not? I am not trying to be a pain; I am just trying to understand the rationale so that I can explain it to others.

Doing stupid things in the past does not equate to being a reason to keep doing so in the future.

Understood. I will see what I can do in glibc land instead. -Ack