基于无线控制器的接口管理——毕业论文

题题（中、英文）（中、英文） 目目 基于无线控制器的接口管理基于无线控制器的接口管理 InterfaceInterface ManagementManagement BasedBased onon thethe WirelessWireless ControllerController m m 作者姓名作者姓名 软件工程软件工程 提交论文日期提交论文日期 年年 月月 代号代号 分类号分类号 学号学号 密级密级 UDC编号编号 学校指导教师姓名职称学校指导教师姓名职称 工程领域工程领域企业指导教师姓名职称企业指导教师姓名职称 摘要摘要 随着无线网络的不断发展，有线网络和无线网络的融合必将成为一种趋势， 新型的网络设备的产生也将成为一种必然，有线无线一体化交换机就是这种设想 的实现。接口管理作为交换机设计中的重要软件组成部分，它在交换机中抽象底 层的硬件驱动，定义完备的接口，给上层管理提供接口，是交换机软件开发的主 要内容，对于交换机的软硬件的管理和交换性能具有十分重要的意义。 本文以某公司的 AX7000 有线无线一体化企业级交换机项目为背景，深入研 究了 Cisco、Juniper 等公司的接口管理设计模式，提出了自己的设计方案。基于 交换机的 PORT 和 VLAN 实现交换机的二层接口、三层接口、协议接口以及各种 特性接口的定义，运用 Port 和 VLAN 之间的关系使接口之间相关联。实现虚拟 网卡驱动以支持三层接口，完成交换机网关功能。添加 ARP 和路由信息学习管 理模块，保证网络安全和数据转发的高效、畅通。最终根据定义的接口实现命令 行的配置功能。 关键词关键词：接口管理 无线控制器 网络 Abstract With the continuous development of wireless networks, the amalgamation of cable and wireless networks will definitely become a trend, and it is inevitable that a late- model network apparatus, such as the Wire and Wireless Integration Switch, will come into being. As an important software components of the Integration Switch, Interface management which abstracts the underlying hardware drive, defines the whole Interface and provides interface for the superior management, has great significance for the management of Integration Switchs software /*建立 Vty 命令节点树 */ vtysh_init_vty ( ); /* 初始化节点和功能模块之间的关系 */ vtysh_config_init ( ); /* 添加开发人员所设计的命令 */ dl_dcli_init( ); 在 Vtysh 的启动过程中调用了 dl_dcli_init( )函数，这个函数调用加载所有开 发人员添加的命令节点以及命令。 Vtysh 提供的命令行节点结构体如下： struct cmd_node enum node_type node; /* 节点类型 */ 第五章 接口管理设计实现 35 char *prompt;/* 命令提示符 */ intvtysh; /* 是否可通过 VTYSH 配置 */ int (*func) (struct vty *); /* 配置文件写函数 */ vector cmd_vector; /* 命令节点序列向量 */ ; 要创建一个新的命令节点则只需要定义一个上面的结构体，再使用下面的函 数加载： void install_node (struct cmd_node *node, int (*func) (struct vty *) 定义新命令主要使用下面的命令结构体： struct cmd_element char *string; /* 命令字符 */ /* 命令响应函数 */ int (*func) (struct cmd_element *, struct vty *, int, char *); char *doc;/* 命令提示 */ int daemon; /* 所属的守护进程 */ vector strvec; /* 命令描述符序列向量 */ int cmdsize; /* 命令序列索引 */ char *config; /* 配置说明 */ ; 然后调用下面的宏实现对上面的命令结构体定义及赋值。最重要的是大括号 中的内容，它是命令解析函数的函数体。 DEFUN( ) /*命令处理函数*/ 以上是在添加新的命令所用到的结构体和 API 函数。通过利用 Vtysh 的已经 设计好的命令组织执行框架，开发人员只需要定义命令字，命令解析函数。无线 控制器的研发是把所有的自定义命令定义在 Dcli 模块。Dcli 中定义的这些函数只 是解析命令中的参数，最终对这个命令的执行是在 npd 模块。npd 根据不同的接 口分别处理，然后返回给用户处理结果。而 npd 和 Vtysh 是两个不同的进程，则 利用 D-Bus 来实现两个进程之间的通信。 在 AX7000 中命令是以功能模块为单元，把各个功能模块的命令全部挂载在 各自的命令节点下面。开发不同的功能模块则要开发人员自己添加对这个功能模 块的控制函数。下面以一个命令的实现为例说明命令模块的设计与实现。 show eth-port PORTNO attributes 这个命令是显示端口的物理属性，PORTNO 基于无线控制器的接口管理 36 就如同一个变量一样，后面的参数解析就是解析命令字中的 PORTNO 部分的字 符。如上面设计所述，首先要用 DEFUN 宏来创建命令结构体，这个结构体如前 所说主要是定义命令字，并且定义解析这个命令字的函数。 show_ethport_cn_attr_cmd 是定义的命令解析函数。这个函数调用 parse_slotport_no 函数把命令字的中的 PORTNO 解析出来，然后通过调用 D-Bus 的 dbus_message_new_method_call 和 dbus_message_append_args 函数把解析出来 的端口索引发到 npd 的处理函数处，然后调用 dbus_message_get_args 函数得到 npd 端函数的处理结果并按照一定的格式输出。 当定义完这个命令体后，要把这个命令结构体挂载到相应的命令节点：void install_element (enum node_type ntype, struct cmd_element *cmd)这样在用户命令行 才能看见这个命令字。这是一个 Vtysh 端的新命令创建的过程，各个功能模块的 命令都是以这种模式实现。 npd 端收到 dcli 传过来的参数，根据 D-Bus 的消息分发机制调用要对这个命 令进行处理的接口管理函数（这就是在第二章中所介绍的 D-Bus 处理模式） 。上 面的命令对应 npd 端的处理函数是 npd_dbus_ethports_interface_show_ethport_attr。此函数首先对参数检查，然后根据 参数调用 nam 模块封装的硬件管理函数，读取当前此端口的信息，并且和接口中 所保存的信息进行比较，把改变的信息保存到定义的接口中，然后把这些端口信 息通过 D-Bus 通道传回到 Dcli 函数，Dcli 函数用一定的格式把这些信息显示出来。 以上只是根据一个接口命令来说明实现过程，当然还有其他的接口命令，只 是这些都比较雷同。Dcli 端根据接口定义命令，D-Bus 根据通道分发消息，npd 端的接口操作函数对传过来的参数进行处理，然后回显处理结果给用户，到真正 起作用的是在报文转发流程中。一个接口可以对应很多的命令，例如一个三层接 口的定义这有三个变量，但是对它的操作有创建，配置，显示，删除。而且命令 不只是对交换芯片的控制，它还要对一些特殊协议进行控制，接口模块相应的定 义了协议的各个管理接口，这些也都是依附于 Port 和 VLAN。 5.2.2 协议模块设计实现 协议模块主要在做的是 STP/RSTP/MSTP生成树协议。这个协议都作为 独立的进程存在于系统中。STP 内部只有一棵 STP tree，因此必然有一条链路要 被 blocking，不会转发数据，只有另外一条链路出现问题时，这条被 blocking 的 链路才会接替之前链路所承担的职责，做数据的转发。无论怎样，总会有一条链 第五章 接口管理设计实现 37 路处于不被使用的状态。随着网络的发展，发现传统的 STP 协议无法满足主备快 速切换的需求，RSTP 的出现解决了延时的问题，它的收敛速度很快31。RSTP 在 STP 基础上额外定义了两种 port role 分别是 alternate 与 backup。另外重新规定 了 port state（端口状态） ，分别为 Discarding、Learning、Forwarding。 STP 和 RSTP 都采用了一棵 STP tree，负载分担不可实现。这也正是 MSTP32产 生的原因，MSTP 可以将多个 VLAN 的生成树映射为一个实例，即 vlan map to a instance，并不需要那么多的生成树，只需要按照冗余链路的条数来得出需要几棵 生成树。如果只有两条链路，并且有 1-1000 个 VLAN，用户可以将 1-500 定义为 instance 1，将 501-1000 定义到 instance 2。只生成两棵树 1 和 2，同样实现了冗余 与负载分担。MSTP 是基于 RSTP 的，MSTP 模式下，交换机可支持 65 个 MST instance，当然每个实例中的 VLAN 数目是无限的。 下面是 RSTP/MSTP 两个主结构体： struct stpm_t STATE_MACH_T* rolesel;/* 端口角色选择状态机 */ /*映射在这个实例上的 VLAN 位图，用于 MSTP */ VLAN_MAP_T vlan_map; /*现在运行的协议版本*/ PROTOCOL_VERSION_T ForceVersion; 另一个是端口结构体： struct port_t STATE_MACH_T* info; /* BPDU 报文信息状态机 */ STATE_MACH_T* roletrns; /* 端口角色切换状态机*/ STATE_MACH_T* sttrans; /*端口状态切换状态机*/ STATE_MACH_T* topoch; /*拓扑变化状态机*/ STATE_MACH_T* transmit; /*发包状态机*/ STATE_MACH_T* receive ; /*收包状态机只用于 MSTP*/ 在单独设计实现协议 STP/RSTP、MSTP 后，为了减少接口管理的复杂度， 增加项目的稳定性，而且 MSTP 是兼容 RSTP 的，因此需要把这两个协议合二为 一。 基于无线控制器的接口管理 38 设计思路是，在 RSTP 和 MSTP 中都有自己的一个变量 ForceVersion，这个 变量主要是配置协议运行版本，2 代表 RSTP，3 代表 MSTP，在协议启动之后通 过配置这个变量就能解决这个问题。 融合以后还要涉及到命令的设计，两个版本虽然兼容，但是 MSTP 的一些参 数在 RSTP 上没有的，还有 MSTP 的配置都要带上实例的 ID。最重要的是 MSTP 的协议会受到 VLAN 的变化发生状态变迁，但是 RSTP 是一个静态的，它只与端 口有关。 针对这些问题的设计方案是把 MSTP 的 instance 0 看成 RSTP。在 MSTP 中所 有的端口都会映射到 instance 0，这个是不会变化的，无论这个端口加入那个 VLAN，这个 VLAN 被映射到其他的 instance，instance 0 上的端口都不会改变， instance 0 是 MSTP 的常量，利用这一属性只要减少 RSTP 的配置命令就可以实现。 而 VLAN 的变化会影响到 MSTP 的状态机，则通过定义 npd 端的管理接口并且建 立接口管理模块和协议模块之间的进程通信通道来实现。 在 npd 端定义的基于端口的协议接口如下： struct stp_info_s booleanstpEnable; enum stp_running_mode mode; unsigned int mstidMAX_MST_ID; unsigned int pathcostMAX_MST_ID; unsigned int prioMAX_MST_ID; unsigned int p2p; unsigned int edge; unsigned intnonstp; enum stp_state_ent_s state; NPD_ETH_PORT_LINK_CHANGE_NOTIFIER_FUNC npd_stp_port_notifier_func; ; 接口管理模块和协议模块之间的通信使用 UNIX socket 实现。这种实现比较 简单，比较安全，唯一的不足是比较慢。UNIX socket 通道的建立和网络编程上 的 socket 建立是同样的，只是它在建立的时候两端各自绑定的地址是临时文件。 发送端把所有的东西都写到和接收端绑定的文件上，然后接收端再读取。 接口管理模块对 socket 控制的几个主要函数如下： npd_rstp_sock_ini( );/*创建 socket*/ npd_read_stp_ports_state( );/*读取协议端的信息*/ npd_cmd_write_ro_rstp( );/*向协议端发送信息*/ 第五章 接口管理设计实现 39 协议端对 socket 控制的几个函数如下： npdSocketInit( ) ;/*创建 socket*/ npdSocketRecvfrom( );/*读取接口管理端的信息*/ npdSocketSendto( ) ;/*向接口管理端发送信息*/ 以配置 MSTP 协议的 instance 为例阐述它们之间的实现方式。Vtysh 端的配 置命是“config spanning-tree map instance MSTID” ，表示把某个 VLAN 映射到 MSTID 的 instace 上。首先 npd 端的 npd_dbus_stp_set_stpid_for_vlan 函数 在接口上保存并写入到芯片上，同时协议端也会收到此消息在 port_t，stpm_t 中 进行保存，然后刷新协议重新进行状态计算。当协议状态出现后，协议通过 socket 把相应 Discarding，Learning，Forwarding 信息发送到 npd 的协议管理模块， 更新接口 stp_info_s 中的协议信息，再调用 nam 中的硬件操作函数写到转发芯片 中，使芯片的报文转发作出相应硬件措施。当用户想看状态机的用行结果则，直 接调要 stp_info_s 中的信息即可，它是硬件信息以及协议状态的备份。 当修改添加删除 VLAN 或增删 VLAN 中的端口时都会影响 MSTP，这些则是 通过在改变 VLAN 或端口的时候调用如下函数实现： /*由于创建 VLAN，则通知新 VLAN 映射到 instance 0*/ npd_mstp_add_vlan_on_mst( ); /*由于删除 VLAN，则通知把 instance n 上映射地这个 VLAN 删除*/ npd_mstp_del_vlan_on_mst( ); /*由于 VLAN 上删除此端口，则把此端口加到 VLAN 所映射的 instance n*/ npd_mstp_add_port( ); /*由于 VLAN 上删除此端口，则把此端口从 VLAN 所映射的 instance n 删除 并且加到 instance 0*/ npd_mstp_del_port( ); 当这些消息通过这四个函数发送到 npd 端，则分别解析它们穿过来的命令字 以及 VLAN ID 或端口索引，调用协议特定的 API 改变 MSTP 的属性，从而影响 状态机的变化。 命令模块和协议模块只是接口管理上层应用的一小部分，但是仍可以说明接 口管理的作用。接口管理对这些配置命令提供接口，抽象协议接口，使协议可以 和硬件及其他接口相互平滑的通信。接口管理的设计实现还有一个很重要的模块 就是驱动模块。 基于无线控制器的接口管理 40 5.3 接口底层驱动模块设计实现 5.3.1 虚拟网卡驱动模块设计实现 在接口管理中除了要给上层用户提供应用接口，另一个作用就是抽象底层驱 动功能，封装相应接口。虚拟网卡驱动在整个系统中有很重要的作用，它支持创 建多个虚拟网络设备，使用户认为这个系统中存在多个网卡设备。每个虚拟网卡 可以如同真实的网卡一样配置 IP 地址，查看网络状态。 AX7000 的硬件架构设计是通过 Marvell 高速转发芯片实现，但当是发给网关 的报文，比如 ICMP，ARP，DHCP 报文等等，这种情况需要一个 TCP/IP 协议栈 来处理这些报文。这种报文的产生首先要创建三层接口，或是基于端口或是基于 VLAN，在同时对 ASIC 芯片进行了设置，也就是说在这个端口或 VLAN 中接收 到的目的 MAC 是设备本身的报文，ASIC 会不经处理把它们通过特殊端口传输到 内存，让接口管理模块去处理。创建三层接口时不光是设置芯片，更重要的是调 用虚拟网卡驱动在内核里创建虚拟网络设备，准备把发给网关的报文送到 Linux 内核的 TCP/IP 协议栈处理，处理完成后又通过虚拟网卡创建的虚拟网络设备把 报文传回，再通过芯片把报文从正确的端口发送出去。 根据上面所述，虚拟网卡驱动的作用有两个，一是用户空间和内核空间之间 传送数据的手段；二是提供三层接口。 在 Linux 中所有的虚拟空间被分为用户空 间和内核空间，内核空间和用户空间不能直接互访的，要通过一定的地址转化或 经过驱动程序提供工的 read,write,ioctl 等函数来实现。驱动的实质就是实现这些 函数。报文要从用户空间到内核空间则就需要一个驱动，另外报文要被送到 Linux 内核的 TCP/IP 协议栈则需要网络设备来实现。由于在 AX7000 中有二十多 个端口，可以配置 4096 个 VLAN，用户可能创建基于这么多的端口，VLAN 三 层接口，给它们配置上 IP，用硬件实现是不现实的，所以就需要随时可以创建或 删除的虚拟网络设备供系统使用。三层接口的功能不只是顺利的让芯片中的报文 传到内核，最重要的是内核的报文也能正确地传回，传回的时候带上正确的转发 信息，比如转发的端口或 VID。只有这样芯片才会做出正确的判断，发送正确的 报文。图 5.2 是虚拟网卡驱动提供的三层接口和交换芯片的关系图。 第五章 接口管理设计实现 41 Interface of Port Interface of VLAN 虚拟网卡 Dev of VLAN Dev of Port Linux TCP/IP协议栈 交换芯片 图 5.2 三层接口和交换芯片关系图 虚拟网卡驱动特殊用途，决定了虚拟网卡设计的特殊性。从结构上来说， kap 驱动并不单纯是实现网卡驱动，同时它还实现了字符设备驱动部分。以字符 设备的方式连接用户态和核心态。图 5.3 是虚拟网卡和物理网卡对比图。 使用虚拟网卡驱动 的进程 使用物理 网卡驱动的进程 字符驱动 Linux TCP/IP协议栈Linux TCP/IP协议栈 虚拟网卡物理网卡 物理层 Ethernet packets 用户态 内核态 图 5.3 虚拟网卡和物理网卡对比图 从上图可以看出，虚拟网卡和物理网卡主要就是虚拟网卡没有硬件支持，它 的报文来去都是通过用户态程序，所以虚拟网卡驱动的设计必须根据前面所说的 两个功能而来，首先要使用户态和内核态能通信，则字符设备驱动可以满足；另 一个要用户态的报文能被 Linux 的 TCP/IP 协议栈所处理，则网络设备驱动可以满 足。接下来的工作就是协调这两个驱动之间的关系。所以 kap 驱动实现方式是通 过字符设备管理网络设备。也就是要创建网络设备，就要通过字符设备提供的 ioctl 函数去创建这个网络设备，创建以后，就能在 shell 命令行下使用 ifconfig 命 令设置虚拟网络设备了，通过生成的字符设备描述符，在程序中使用 read 和 write 函数就能读取或发送给虚拟的网卡数据了。 基于无线控制器的接口管理 42 下面是定义的 kap 驱动中的主要结构体。每个设备都有自己的私有数据结构， 这个里面保存了各自的一些私有数据。在 kap 驱动程序中，因为要通过一个字符 设备控制所有的网络设备，则通过所有的设备共享一个私有数据，私有数据中有 收发包队列，所有的网络设备表，网络设备的 MAC 地址等等。 struct kap_struct wait_queue_head_tread_wait; /*进程等待队列*/ struct sk_buff_headreadq;/*报文收发队列*/ struct user_netdevice *udev_index; /*网络设备表*/ struct net_device_statsstats; /*网络设备状态*/ unsigned int if_flags; /*网络设备标志*/ /*网络设备 MAC 地址和系统 MAC 相同*/ unsigned char if_mac_addr6; ; kap_struct 代表的是一个字符设备的私有数据，它里面的 udev_index 中存储 了所有的网络设备，它们两个之间的关系就说明了字符设备驱动和网络设备驱动 之间的关系，也就是一对多的关系。这样的设计就是为了实现前面所提到的要创 建基于 Port 和 VLAN 的多个三层接口。定义设备结构体 struct user_netdevice 其中 就包含了网络设备类型，即接口类型，是 Port 模式还是 VLAN 模式。只有这样 才能把芯片上的端口和三层接口之间的关系联系起来，更重要的作用是报文在 Linux TCP/IP 协议栈进行处理的时候要和网络设备绑定，驱动就根据传入的报文 属性选择对应的它所属的网络设备以及类型。同时当报文从内核协议栈出来的时 候，也会根据和报文绑定的网络设备，查找出这个设备对应的设备类型，然后给 报文封装上相应的 Port 或 VLAN 信息到用户态，然后用户态程序会根据这些信 息给报文做一定的芯片可以认识的标记，来保证报文在芯片中的正确发送。下面 是 struct user_netdevice 的具体定义。 struct user_netdevice struct net_device* dev; /*内核网络设备结构体*/ KAP_DEV_TYPE dev_type; /*赋予网络设备的类型*/ unsigned int l3_index; /*网络设备在内核中的索引*/ unsigned int l2_index; /*端口模式的网络设备所对应的端口索引*/ unsigned int vId;/*VLAN 模式的网络设备所对应 VLAN ID*/ ; struct net_device33结构是 linux 内核提供的统一网络设备结构，可以说在内 第五章 接口管理设计实现 43 核中它就代表了一个网络设备，而虚拟网卡就是利用了这一特点来实现想要的功 能。Kap 驱动中所涉及到这个结构体里面主要是有以下方面： 1.标识变量 int ifindex 全局唯一的设备 ID。在每个设备注册时，调用 dev_new_index 生成。 因此在 kap 字符设备驱动中的网络设备表是以它索引的，还有在 npd 中，对三层 接口的表示也是通过它。 2.配置变量 有些参数可以在内核初始化此类设备时设置一个缺省值，而有些参数就需要 留给设备驱动来填充。可以在运行时通过 shell 命令或 ioctl 来修改。在 kap 中最 常设置的就是网络设备的 flags，表示设备现在模式，主要有这几种： IFF_UP、IFF_DOWN、IFF_MULTICAST 等。 3.函数指针表 net_device 结构中同样包括了许多函数指针。这些函数指针主要完成以下几 个功能，收发数据帧，添加或分析链路层数据包头等。kap 驱动中主要实现的结 构体中的一些函数指针。 open：kap_net_open(struct net_device *dev)； close：kap _net_close(struct net_device *dev)； /*数据包发送函数*/ hard_start_xmit：kap _net_xmit(struct sk_buff *skb, struct net_device *dev)； /*得到网络接口的一些统计数据函数*/ get_stats：kap_net_stats(struct net_device *dev)； 如第二章所说，无论是字符设备还是块设备，用户对设备的操作都是通过虚 拟文件系统(VFS)转化为设备驱动与硬件操作程序交互。即使是访问网络设备的 socket 接口，也是通过 VFS 实现的。Linux 通过 VFS 为用户提供了一个统一的设 备访问接口，使用户能够透明地访问设备驱动程序。所有的硬件设备都可以使用 操作系统的系统调用接口来打开、关闭、读写和 I/O 控制，而驱动程序的主要任 务就是实现这些系统调用函数。 在Linux中，字符设备和块设备统一以文件的方式访问，访问它们的接口是统 一的，都是通过file_opreation结构体中定义的函数来访问。所以在驱动程序中， 首先要根据驱动程序的功能，完成file_operation结构中函数实现。不需要的函数 接口可以直接在file_operation结构中初始化为NULL。file_operation变量会在驱动 程序初始化时注册到系统内部。当操作系统对设备操作时，会调用驱动程序注册 的file_operation结构中的函数指针。虚拟网卡的字符设备的文件操作结构体如下： static struct file_operations kap_fops = 基于无线控制器的接口管理 44 .owner= THIS_MODULE, .read = kap_chr_read, .write = kap_chr_write, .ioctl= kap_chr_ioctl, .compat_ioctl = bm_compat_ioctl, .open= kap_chr_open, .release = kap_chr_close, ; read，读操作，参数buf为存放读取结果的缓冲区，count为所要读取的数据长 度。返回值为负表示读取操作发生错误；否则，返回实际读取的字节数。在虚拟 网卡驱动中，read函数的主要功能就是用户进程从内核空间得到要发送的报文。 write，写操作，与read类似，只是write是从用户空间把报文送到内核空间。 ioctl，读、写以外的其他操作，参数cmd为自定义的命令。在虚拟网卡驱动 中，它的主要作用就是对网卡设备的控制，例如创建、删除、修改设备Link状态、 IP和MAC地址等等。 compat_ioctl，Linux2.6 对 64bit kernel 在 struct file_operation 中增加的成员， 如果 compat 收到的最后参数 arg 是一个用户态指针, 它在用户态是 32 位的，在 内核中为了保证安全，可以使用 compat_ptr(art)宏将其安全的转化为一个 64 位的 指针(仍然是用户指针)34。 open，打开设备准备进行I/O操作。返回0表示打开成功，返回负数表示失败。 release，即close操作。 由于这是一个虚拟的网卡驱动，不是PCI设备，也没有硬件中断处理，所以 在这个驱动中减少了注册中断和中断响应函数。以上是kap中所实现的字符驱动 的函数。字符设备最主要的工作就是read，write，ioctl。 在内核中利用 misc_register() 函数将该驱动注册为非标准字符设备驱动，提 供字符设备具有的各种程序接口。在 Linux shell 下输入下面的两个命令后就可以 使用应用程序来调用驱动做用户和内核之间的交互。 #modprobe kap #mknod /net/dev/kap c 10 200 通过上面的第一个命令在 Linux 操作系统上加载了这个虚拟网卡驱动35，但 是要让应用程序能调用驱动函数，需要在 Linux 的 net/dev 目录下创建一个字符设 备的节点。第二个命令的意思是参数 c 表示是字符设备, 10 和 200 分别是主设备 号和次设备号。 当打开一个 kap 设备时，open 函数将调用 kap_chr_open()函数，其中将完成 第五章 接口管理设计实现 45 一些重要的初始化过程，包括设置网卡驱动部分的初始化函数及网络缓冲区链表 的初始化和等待队列的初始化。kap 驱动中网卡的注册被嵌入了字符驱动的 ioctl 程序中，它是通过对字符设备文件描述符利用自定义的 ioctl 设置标志 KAPADDIFF 完成网卡的注册的，KAPDELIFF 完成网卡释放。图 5.4 是创建虚拟 网络设备流程示意图。 首先使用 open 函数打开在/net/dev/处注册的字符设备，返回设备描述符。如 果需要创建三层接口则调用 ioctl()函数操作字符设备文件描述符，命令标志为 KAPADDIFF，传入参数 struct if_cfg_struct。这个结构中主要包含了这个三层接 口的类型是 Port 或 VLAN，还有端口索引和 VLAN ID，当处理完后还要通过这 个结构体把创建的网络设备在内核中的索引传到 npd 端进行保存。 struct if_cfg_struct charif_name16;/* if name, e.g. “en0“ */ KAP_DEV_TYPE dev_type; KAP_DEV_LINK_STATUS dev_state; unsigned int l3_index; unsigned int l2_index; unsigned int vId; unsigned int netmask; unsigned char mac_addr6; ; 基于无线控制器的接口管理 46 Open打开设备节点 调用ioctl进入内核 从用户空间拷贝参数 参数是否正确 创建user_dev、net_device 初始化dev 注册dev 绑定dev与芯片关系 把user_dev用ifindex索引到 设备表中 结束 返回产生的ifindex 是否成功 释放资源返回错误码 正确 错误 成功 失败 开始 图 5.4 创建虚拟网络设备流程图 到了内核态的驱动程序里， kap_chr_ioctl 函数根据命令标志，找到相应的处 理函数 kap_create_iff 创建网络设备。首先调用 alloc_dev 分配 struct net_device， 同时调用 kap_setup 给新的 dev 挂接网卡驱动的各个处理程序。最后此函数完成 非常重要的一步操作，就是对网卡驱动进行注册 register_netdev()，并且把传进来 的接口信息和新的设备关联起来，后面的报文转发都要使用这些信息。 kap 设备提供的虚拟网卡驱动，从 tcp/ip 协议栈的角度而言，它和真实网卡 驱动并没有差别。从驱动程序的角度来说，它和真实网卡的不同表现在目前 kap 设备获取的数据不是来自物理链路，而是来自用户区，kap 设备驱动通过字符设 备文件来实现数据从用户区的获取。发送数据时 kap 设备也不是发送到物理链路， 而是通过字符设备发送至用户区，再由用户区程序通过其他渠道发送。 使用 kap 网卡的程序经过协议栈把数据传送给驱动程序，驱动程序调用注册 好的 hard_start_xmit 函数发送， hard_start_xmit 函数又会调用 kap_net_xmit 函数， 其中 skb 将会被加入 skb 链表，然后唤醒被阻塞的使用 kap 设备字符驱动读数据 的进程，接着 kap 设备的字符驱动部分调用其 kap_chr_read()过程读取 skb 链表， 第五章 接口管理设计实现 47 并将每一个读到的 skb 发往用户区，完成虚拟网卡的数据发送。 当使用 write()系统调用向 kap 设备的字符设备文件写入数据时， kap_chr_write 函数将被调用，它使用 kap_get_user 从用户区接受数据，其中将数 据存入 skb 中，然后调用关键的函数 netif_rx_ni(skb) 将 skb 送给 tcp/ip 协议栈处 理，完成虚拟网卡的数据接收。read 和 write 的流程图如图 5.5 所示。 调用write进入内核 从用户空间拷贝参数 参数是否正确 创建sk_buff用报文初始化 从用户空间拷贝报文 作报文以太网检查 报文送内核 记录收包字节 结束 是否通过 释放资源返回错误码 正确 错误 是 否 调用read进入内核 从用户空间拷贝参数 参数是否正确 返回错误码 从发包队列取报文 判断报文长度 内核拷贝报文到用户空间 内核拷贝属性到用户空间 结束 补够64字节 正确 错误 根据参数查找dev 是否有报文 是否大于64字节 写入报文对应属性 否 是 是 否 开始开始 图 5.5 虚拟网卡 write、read 流程图 Linux 虚拟网卡驱动实现了用户空间和内核空间的通信，让到达内存的报文 可以进入内核协议栈处理。并且为交换机提供了三层接口使交换机能够自动处理 三层转发。三层接口的类型有端口和 VLAN 之分，两种不同的接口为交换机提供 了多种不同的功能。但是这些都是在有物理层支持和收发报文的基础下实现的。 而 Marvell 高速转发芯片做了这个物理层的支持。相应的 Marvell 芯片驱动的实现 在交换机的功能中起至关重要的作用。 5.3.2 交换芯片驱动模块设计实现 Marvell 芯片是挂载在 PCI 总线上的 CPU 外设。虽然它和网卡有些相似，但 是它本身有处理报文的能力，所以它在内核中注册不是以网络设备去注册，而是 基于无线控制器的接口管理 48 注册成字符设备。当有些报文的处理要到特定的协议去，则通过驱动的应用程序 实现的 DMA 机制来完成报文从外设到用户空间的传递，更重要的是用户程序对 芯片寄存器的操作。Marvell 芯片的驱动是典型的字符设备驱动。设备驱动所实现 的 file_opreation 结构体实现如下： static struct file_operations prestera_fops = .llseek = prestera_lseek, .read = prestera_read, .write = prestera_write, .ioctl = prestera_ioctl, .compat_ioctl = prestera_compat_ioctl, .mmap = prestera_mmap, .open = prestera_open, .release= prestera_release ; read，write，open，release，ioctl 同一般字符设备的作用。 lseek，移动文件指针的位置，只能用于可以随机存取的设备。 mmap， 用于把设备的内容映射到地址空间，一般只有块设备驱动程序使用 compat_ioctl，Linux2.6 对 64bit kernel 在 struct file_operation 中增加的成员， 如果 compat 收到的最后参数 arg 是一个用户态指针, 它在用户态是 32 位的，在 内核中为了保证安全，可以使用 compat_ptr(art)宏将其安全的转化为一个 64 位的 指针(仍然是用户指针)。 建立自己的私有数据，创建 proc 文件，可以在/proc/目录下对驱动的一些参 数进行修改36。初始化驱动信号灯和时钟周期。Marvell 芯片的驱动主要作用是 提供 read，write，mmap 函数，让应用程序可以方便访问到芯片的内存空间。 基于上面的驱动，Marvell 厂商提供了很庞大的驱动应用开发包。从芯片的初 始化，到芯片的 DMA 机制，还有很多的功能控制函数。在 Marvell 芯片和虚拟 网卡之间还需要专门的收发报文线程，所以基于 Marvell 驱动应用开发包，在 npd 中创建两个线程一个收报文一个发送报文。 收报文线程的主函数是 cpssDxChPacketRxAdapterStartReceive。首先此函数 要做的是把 Marvell 芯片传来的报文中所带的特殊标记去掉，并且分析特殊标记。 然后判断报文类型以决定是送协议模块还是调用虚拟网卡送内核。接着根据特殊 标记中端口信息和 VLAN ID 查找对应的三层接口的索引，也就是虚拟网络设备 的索引。如果找到则把这些信息和报文通过虚拟网卡传到内核中；如果没有则把 报文丢弃。如果报文是 ARP 则首先要送 ARP 路由学习模块进行处理，最后才送 第五章 接口管理设计实现 49 内核。 发送报文主线程的函数是 appDemoPacketTxVirtNetIfTask。首先调用虚拟网 的 read 函数读取报文，然后根据和报文一块传出来的虚拟网络设备属性，给这个 报文建立特殊标记，然后发送到 Marvell 芯片中，让芯片把此报文发送出去。 在系统中，还有主板上的 Cavium 网卡驱动，至此有了这三个驱动，通过接 口管理模块对这三者的封装，配置，就可以实现第四章中数据流的处理业务。虚 拟网卡驱动给接口管理提供的是两种模式的三层接口，而 ASIC 芯片和 Cavium 网卡则提供了相应的二层接口和不同的网络划分。接口管理就是使交换机经过配 置后让这些二层三层的接口正确的串通，网络高速畅通，给用户的网络接入提供 优质服务。 5.4 接口管理设计实现 命令行模块，协议模块，驱动模块等等这些模块都是围绕在接口管理的周围。 它们有的是给接口管理提供接口，有的在应用接口管理提供的服务。因此说接口 管理的是一个错综复杂的软件。 5.4.1 Port 接口 AX7000 上的端口就是所看到的网口。它的直观功能就是插上网线能上网。 但是这种能上网是要经过物理层的协议，链路层，还有网络层甚至是传输层一直 到应用层通力合作得以实现。 AX7000 中使用了两块硬件芯片，一块是 275 芯片，另一块是 804 芯片。这 两个芯片都使用同一个驱动。所以在 Marvell 提供的开发包中，每个函数都有一 个参数devNum 标识设备号。图 5.6 显示了硬件结构各种物理端口。 从图中可以看出 AX7000 中的 275 和 804 芯片引出端口是 24 个 GE 和 4 个 10GE 口。这些端口提供给用户使用，就需要有相应的方法能管理它们。在软件 中就需要相对应的接口去表征它，就如同网络设备的 struct net_device 一样。 在交换机中最重要的两个功能就是 Port 和 VLAN。后续的开发都是基于这两 个功能实现其他功能。比如像三层接口，根据用户需求，它可以有两种类型，一 基于无线控制器的接口管理 50 Cavium CN58xx/38xx DDR RLD RAM Chip（SPI4.2/XAUI） Marvell MVL Switch Chip(24GE+3*10GE) Boot Flash FPGA/ CPLD Control GPIO 4*Control Control SPI4.2 XAUI 4*RGMII South Bridge 64bit 133M PCI-X 4*PCI4*（6GE） 2*（XGE） 2*UART 连接到4个Slot MAC 管理网口主控直接出210GE口 WiCtrl主控系统逻辑图 Hard Drive Super I/O PCI Memory Stick ConsoleDebug/Aux 调试网口 2*PCI-x 主控直接出 1PCMCIA插槽 主控直接出2*GE Combo( 光电互换） 图 5.6 AX7000 物理端口图 种是基于端口的，一种是基于 VLAN 的；上一节所说的协议模块，当它运行在 MSTP 版本时，VLAN 的改变就会影响到协议的状态机，还有 FDB，QoS，ACL 等等这些要么与 Port 有关，要么与 VLAN 有关。基于这一层考虑，无线控制器 的接口管理是通过设计两个核心结构体 eth_port_s 和 vlan_s 来实现。接口管理模 块设计的 Port 结构体如下： struct eth_port_s enum eth_port_type_e port_type; /* 32 bits of attributes, defined in npd_sysdef.h Bits 011 to have 12 kinds of binary attributes Bits 1215 to represent 4bits 16 kinds of speed, Bits 1631 reserved for future more attributes */ unsigned int attr_bitmap; unsigned int mtu; struct eth_port_func_data_s funcs; struct eth_port_counter_s counters; ; 这个结构体中，枚举变量 port_type 标识这个物理端口的类型，是普通的电口， 还是光口或者是 10G 口。attr_bitmap 变量标识了现在这个端口所支持的物理属性。 第五章 接口管理设计实现 51 mtu 标识这个端口现在所能支持的最大的二层报文字节。funcs 标识端口所有的功 能。counters 是这个端口上所有流经报文的统计。 Marvell 芯片的端口物理属性是以下几种： 1. 端口管理，当端口进入管理状态后才能进行正常的报文收发，退出管理 状态后，不能发包；收到的报文包被丢弃。 2.端口速率，配置端口速率是 10M/100M/1000M。 3.端口自协商，端口自协商有速率，