Linux kernel practices

Kernel version: 2.6.34

Realize the idea:

The flow of messages in the network protocol stack, for the reception, is the message of the process of shelling, because the message is known as input, as long as the resolution of the protocol number, for the sending, is the layer of the sending function of nested calls, because there is no known input, only in advance of the design of the protocol layer structure. But no matter how the message flows, the core is the message device (SKB->DEV) changes, the equivalent of the transfer between the various layers of the bar.

According to the above thought, the BRCM protocol receives the processing as the module Brcm_packet_type joins in the ptype_base to be possible; The BRCM protocol sends the processing to be more complex, the sending nesting call is completely dependent on the device to drive, therefore has a newly created device x, Insert between the VLAN device and the network card device.

Therefore, at least have brcm_packet_type to join Ptype_base and Register_brcm_dev () to register device x with the system. For further consideration, device x is stored in the global init_net, but we also need to know what kind of organizational relationship the device X has with the VLAN device and the NIC device, so a brcm_group_hash is designed here to store it. To respond to events of interest to the device, add your own notifier to the Netdev_chain. In addition, for user space to have certain control ability (such as create, delete), also need to add BRCM related IOCTL call. To make it look more complete, a new device should have a corresponding entry in the proc to debug and view the device.

From the simplest start

To allow the network protocol stack to receive a new protocol is very simple, because there is already a message as input, we have to do is to write good brcm_packet_type, and then in the registration module to do only one thing: Dev_add_pack.

 static int __init brcm_proto_init (void) {dev_add_pack (&brcm_packet_type); static struct Packet_type Brcm_packet_type __read_mostly = {. Type = Cpu_to_be16 (ETH_P_BRCM),. Func = Brcm_     

SKB_RECV,/* BRCM Receive method */}; int brcm_skb_recv (struct sk_buff *skb, struct net_device *dev, struct packet_type *ptype, struct net_device *orig     
 _dev) {struct BRCM_HDR *bhdr;     

 struct Brcm_rx_stats *rx_stats;     
 SKB = Skb_share_check (SKB, gfp_atomic);     
 if (!SKB) goto Err_free;     

 BHDR = (struct BRCM_HDR *) skb->data;     
 Rcu_read_lock ();     
 Skb_pull_rcsum (SKB, Brcm_hlen);     
 Set protocol Skb->protocol = bhdr->brcm_encapsulated_proto;     
 Reorder SKB SKB = Brcm_check_reorder_header (SKB);     

 if (!SKB) goto Err_unlock;     
 Netif_rx (SKB);     
 Rcu_read_unlock ();     

return net_rx_success;     

Err_unlock:rcu_read_unlock ();     
 ERR_FREE:KFREE_SKB (SKB);return net_rx_drop; }

After registering this module, the protocol stack can receive the message with BRCM header normally, in the code ETH_P_BRCM is the BRCM protocol number, Brcm_hlen is the BRCM header length. It is precisely because of the message as input, the reception becomes very simple.

But this is only able to receive, send the message or not with BRCM header, and received this code is very rough, no change SKB equipment, no record traffic, no BRCM header for meaningful processing, the following one to add.