CN105939365A - 主控板用户态从业务板内核态获取数据的方法及装置 - Google Patents

Abstract

本发明提供一种主控板与业务板间传输数据的方法及装置，其中，方法包括：获取用户请求数据；通过系统调用通信机制将用户请求数据发送到内核态；通过内核态板间通信机制将用户请求报文发送给业务板内核态；当操作类型为读操作时，建立netlink服务端；通过netlink客户端将接收到的应答数据发送给netlink服务端；netlink服务端接收到应答数据后，返回到用户态程序；用户态程序解析应答数据，组织成用户理解的形式呈现给用户。采用本发明实施例提供的方法可以实现主控板用户态程序直接高效、实时地从业务板内核态程序读取数据。

Description

主控板用户态从业务板内核态获取数据的方法及装置

技术领域

本发明涉及网络通信技术领域，尤其涉及一种主控板用户态从业务板内核态读取数据的方法及装置。

背景技术

随着互联网的迅猛发展,内核态进程和用户态进程之间的数据交互越来越频繁,并且交互的数据量越来越大。

现有的一体化分布式网络设备一般由设备机框和安装在机框上的一至两块主控板卡、若干业务板卡和交换板卡构成，其中，主控板卡用于设备管理控制，业务板卡和交换板卡用于业务处理。由于一体化机制，用户不直接管理业务板卡，而由主控板卡统一管理。用户在管理设备时，需要读取业务板卡的软件版本信息以及业务板在业务处理过程中产生的会话信息和日志信息等，上述过程为主控板卡用户态从业务板卡内核态读取数据的过程。

现有技术主控板用户态从业务板内核态读取数据的过程为:主控板用户态先连接到业务板用户态、再由业务板用户态通过系统调用等方式从业务板内核态读取所需信息的数据。在这一过程中，系统需要分别在主控板、业务板的用户态/内核态间反复切换，虽然大部分过程都封装在标准网络通信流程中，但数据反复传送和重新组织，不仅拉长了处理流程，容易引入错误，而且造成CPU和通道繁忙，对系统性能造成不良影响。

发明内容

有鉴于此，本发明提供一种主控板与业务板间传输数据的方法，应用于一体化分布式网关设备的主控板中，上述方法包括：获取用户请求数据；通过系统调用通信机制将上述用户请求数据发送到内核态；通过内核态板间通信机制将上述用户请求数据对应的用户请求报文发送给对应业务板的内核态程序，以使上述业务板的内核态程序组织相应的应答数据，并将上述应答数据传输到主控板的用户态程序；查询上述用户请求数据中的操作类型，当上述操作类型为读操作时，建立用于监听主控板内核态消息的netlink服务端；接收来自业务板内核态的数据，通过netlink客户端将应答数据发送给用户态程序的上述netlink服务端；上述netlink服务端接收到上述应答数据后，将上述应答数据返回到用户态程序；上述用户态程序解析上述应答数据，组织成用户理解的形式并呈现给上述用户。

可选地，上述主控板与业务板间传输数据的方法还包括：

系统初始化时，主控板内核态程序建立面向主控板用户态的netlink客户端，以使上述netlink客户端在监听到来自业务板内核态的消息后，将上述消息发送给主控板的用户态程序。

可选地，上述获取用户请求数据，包括：接收用户请求；根据上述用户请求组织目标数据，上述目标数据至少包括：通信类型、业务板槽号、操作类型；将上述目标数据按照预设数据格式封装为用户请求数据。

可选地，上述通过内核态板间通信机制将上述用户请求数据对应的用户请求报文发送给对应业务板的内核态程序，以使上述业务板内核态程序组织相应的应答数据，返回到用户态程序，包括：从上述用户请求数据中解析业务板槽号；将上述用户请求数据按照板间通信机制所需报文格式封装成用户请求报文；通过内核态板间通信机制将上述用户请求报文发送给上述业务板槽号对应业务板的内核态程序，以使上述业务板内核态程序组织相应的应答数据；上述系统调用返回到用户态程序。

可选地，上述查询上述用户请求数据中的操作类型，当上述操作类型为读操作时，建立用于监听主控板内核态消息的netlink服务端；包括：从上述目标数据中查询业务板槽号和操作类型；判断上述操作类型是否为表示从上述业务板槽号对应的业务板中读取数据的读操作；若上述操作类型为读操作，则建立netlink服务端，以使上述netlink服务端监听主控板内核态消息；若上述操作类型不是读操作，则返回到用户态程序。

可选地，上述接收到来自业务板内核态的数据，通过netlink客户端将应答数据发送给用户态程序的上述netlink服务端；包括：接收上述业务板通过内核态板间通信机制返回的数据；判断上述数据中是否包含板间系统调用标记；若上述数据中包含板间系统调用标记，表示该数据为应答数据，通过netlink客户端将上述应答数据发送给上述netlink服务端；若上述应答数据中不包含板间系统调用标记，表示该数据不是应答数据，结束流程。

可选地，上述主控板与业务板间传输数据的方法还包括：设置上述netlink服务端等待内核态消息的时间阈值；若上述netlink服务端等待内核态消息的时间达到上述时间阈值后未获取到应答数据，则返回失败信息。

另一方面，本发明实施例公开了一种主控板与业务板间传输数据的方法，应用于一体化分布式网关设备的业务板中，上述方法包括：接收主控板内核态通过内核态板间通信机制发送的用户请求报文；解析上述用户请求报文中的操作类型、模块操作码、模块数据信息，组织上述信息对应的数据，并为上述数据作上板间系统调用标记，形成应答数据；将上述应答数据通过上述内核态板间通信机制发送给主控板内核态程序。

相应的，提供了一种主控板与业务板间传输数据的装置，设置于一体化分布式网关的主控板中，上述装置包括：

用户请求获取模块，用于获取用户请求数据；

第一发送模块，用于通过系统调用通信机制将上述用户请求数据发送到内核态；

第二发送模块，用于通过内核态板间通信机制将上述用户请求数据对应的用户请求报文发送给对应业务板的内核态程序，以使上述业务板的内核态程序组织相应的应答数据，并将上述应答数据传输到主控板的用户态程序；

netlink服务端建立模块，用于查询上述用户请求数据中操作类型，当上述操作类型为读操作时，建立用于监听主控板内核态消息的netlink服务端；

第三发送模块，用于接收来自业务板内核态的数据，通过netlink客户端将应答数据发送给用户态程序的上述netlink服务端；

接收模块，用于在上述netlink服务端接收到上述应答数据后，将上述应答数据返回到用户态程序；

反馈模块，用于上述用户态程序解析上述应答数据，组织成用户理解的形式并呈现给上述用户。

可选的，上述装置还包括：

netlink客户端建立模块，用于在系统初始化时，主控板内核态程序建立面向主控板用户态的netlink客户端，以使上述netlink客户端在监听到来自业务板内核态的消息后，将上述消息发送给主控板的用户态程序。

可选的，上述用户请求获取模块，包括：请求接收单元，用于接收用户请求；目标数据组织单元，用于根据上述用户请求组织目标数据，上述目标数据至少包括：通信类型、业务板槽号、操作类型；数据封装单元，用于将上述目标数据按照预设数据格式封装为用户请求数据。

可选的，上述第二发送模块包括：

第一查询单元，用于从上述用户请求数据中解析业务板槽号；

封装单元，用于将上述用户请求数据按照板间通信机制所需报文格式封装成用户请求报文；

第二发送单元，用于通过内核态板间通信机制将上述用户请求报文发送给上述业务板槽号对应业务板的内核态程序，以使上述业务板内核态程序组织相应的应答数据；

第一返回单元，用于上述系统调用返回到用户态程序。

可选的，上述netlink服务端建立模块，包括：

第二查询单元，用于从上述目标数据中查询业务板槽号和操作类型；

第一判断单元，用于判断上述操作类型是否为表示从上述业务板槽号对应的业务板读取数据的读操作；

netlink服务端建立单元，用于在上述操作类型为读操作的情况下，建立netlink服务端，以使上述netlink服务端监听主控板内核态消息；

第二返回单元，用于在上述操作类型不是读操作的情况下，返回到用户态程序。

可选的，上述第三发送模块包括：

接收单元，用于接收上述业务板通过内核态板间通信机制返回的数据；

第二判断单元，用于判断上述数据中是否包含板间系统调用标记；

第三发送单元，用于在上述数据中包含板间系统调用标记的情况下，通过netlink客户端将应答数据发送给上述netlink服务端；

结束单元，用于在上述数据中不包含板间系统调用标记的情况下，结束流程。

可选的，上述netlink服务端建立模块还包括：

等待期限设置单元，用于设置上述netlink服务端等待内核消息的时间阈值；

信息提示单元，用于在上述netlink服务端等待内核消息的时间达到上述时间阈值后未获取到应答数据的情况下，返回失败信息。

还提供了一种主控板与业务板间传输数据的装置，设置于一体化分布式网关设备的业务板中，上述装置包括：

接收模块，用于接收主控板内核态通过内核态板间通信机制发送的用户请求报文；

数据组织模块，用于解析上述用户请求报文中的操作类型、模块操作码、模块数据信息，组织上述信息对应的数据，并为上述数据作上板间系统调用标记，形成应答数据；

发送模块，用于将上述应答数据通过上述内核态板间通信机制发送给主控板内核态程序。

具体地，本发明是通过如下技术方案实现的：

采用本发明实施例提供的板间通信方法，将Conplat系统调用、Conplat平台内核态板间通信机制和LINUX netlink通信机制结合起来，以内嵌了内核态板间通信机制的Conplat系统调用为主体，通过netlink机制解决Conplat系统调用不能从内核态主动发起的问题，在一体化分布式网关中实现了从主控板用户态程序直接从业务板内核态程序读取数据，而不使用标准socket编程机制，无需业务板用户态程序参与，从而将主控板进程和业务板进程在用户态/内核态间切换次数减到最少，并将数据传输次数减到最少，有效缩短了数据传输路径，减少了故障点，提高了系统性能和实时性，改善了系统稳定性和用户体验。

附图说明

图1是现有技术主控板用户态从业务板内核态读取数据的示意图；

图2是本发明主控板与业务板间传输数据的方法实施例一的流程图；

图3是本发明方法实施例中步骤11具体实施方式的流程图；

图4是本发明方法实施例中步骤13具体实施方式的流程图；

图5是本发明方法实施例中步骤14具体实施方式的流程图；

图6是本发明方法实施例中步骤15具体实施方式的流程图；

图7是本发明主控板与业务板间传输数据的方法实施例二的流程图；

图8是本发明主控板与业务板间传输数据的方法实施例的流程图；

图9是本发明主控板与业务板间传输数据的方法的示意图；

图10是本发明主控板与业务板间传输数据的装置实施例一的结构框图；

图11是发明装置实施例中用户请求获取模块的结构框图；

图12是本发明装置实施例中第二发送模块的结构框图；

图13是本发明装置实施例中netlink服务端建立模块的结构框图；

图14是本发明装置实施例中netlink服务端建立模块的另一结构框图；

图15是本发明装置实施例中第三发送模块的结构框图；

图16是本发明主控板与业务板间传输数据的装置实施例二的结构框图；

图17是本发明主控板与业务板间传输数据的装置实施例的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请中可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

一体化分布式网关设备是一种框式设备，由设备机框和安装在该设备机框上的板卡构成。上述板卡包括：一至两块主控板、若干块业务板和交换板。其中，上述主控板用于设备管理控制；业务板和交换板用于业务处理。主控板和业务板都设置有CPU，分别运行相对独立的系统，相应对整机或本板卡进行管理控制和业务处理。

由于上述一体化分布式网关设备的一体化机制，用户不直接管理业务板卡，而通过主控板卡统一对上述网关设备进行管理。用户对网关设备的管理可以分为以下几种情况：

第一种情况：用户向业务板下发配置信息

用户需要向业务板卡下发配置信息时，通过主控板的管理界面如WEB页面或命令行终端进行配置操作。主控板负责将配置信息组织成业务板可识别的数据并下发给业务板。

上述配置信息保存在主控板的非易失性存储器如硬盘或CF卡上。业务板不在非易失性存储器上保存配置信息。

当业务板因断电或故障发生重启时，主控板负责将该业务板的配置信息重新下发到该业务板中。

第二种情况：用户需要向业务板安装、更新或卸载软件版本文件

用户通过主控板的管理界面如WEB页面或命令行终端向业务板安装软件版本文件或更新主版本、卸载软件版本文件等相关操作时，由主控板负责将对应的软件版本文件传输到业务板的非易失性存储器上。

第三种情况：用户向业务板下发安全策略、转发表项

业务板进行安全业务处理、流量转发等操作时，需要使用由主控板CPU生成的安全策略、转发表项等动态数据。

第四种情况：用户需要从业务板获取业务处理过程中产生的状态信息和统计数据

用户在管理设备时，也需要读取业务板的软件版本信息，以及业务板在业务处理过程中产生的状态信息和统计数据等。其中，上述状态信息如会话信息和日志信息等；上述统计信息如流量统计信息等。

上述四种情况对应的用户对网关设备的管理过程均通过主控板与业务板的通信实现。而主控板与业务板间的通信的主要就是主控板与业务板间数据的访问和传输。对于主控板和业务板间数据的访问，首先需要明确各种数据在板卡中的存储位置及访问方式。

在一体化分布式网关设备中，无论是主控板还是业务板，都设置有易失性存储介质和非易失性存储介质。其中，上述易失性存储介质可以包括内存等；内存又可以包括内核态部分和用户态部分，即内核态内存和用户态内存。上述非易失性存储介质可以是闪存、硬盘或CF卡等。

根据数据在板卡中的存储位置及访问方式，可以划分为以下几种数据：

第一种数据：存储在主控板内存的内核态部分，包括：转发表项、安全策略等动态数据。

上述第一种数据既用于主控板自身进行业务处理和流量转发；也要被主控板发送到业务板上，由业务板内核依据上述动态数据进行业务处理和流量转发。

上述第一种数据需要通过主控板的内核态接口进行访问。

第二种数据：存储在主控板的非易失性存储介质中，包括：整机配置、软件版本文件、各类日志文件等数据。

上述第二种数据需要通过主控板的用户态接口进行访问。

第三种数据：存储在主控板的用户态内存中，包括：部分业务处理所需数据，例如OSPF(Open Shortest Path First，开放式最短路径优先)协议生成的动态路由表项、DHCP(Dynamic Host Configuration Protocol，动态主机配置协议)生成的租约信息等。

上述第三种数据也需要通过主控板的用户态接口进行访问。

第四种数据：存储在业务板内存的内核态部分，包括：由主控板CPU生成并传输到业务板的配置信息如转发表项和安全策略等，即从主控板接收到的该业务板的配置信息；以及在业务处理过程中产生的状态信息和统计数据如会话信息、日志信息、流量统计信息等。

对应上述第四种情况，在用户管理设备过程中，用户需要读取业务板内核态生成的会话信息和日志信息等动态数据时，为用户提供相应数据。

上述第四种数据需要通过业务板的内核态接口进行访问。

第五种数据：存储在业务板的非易失性存储介质中，包括：软件版本文件和一些设备基本信息；

上述第五种数据需要通过业务板的用户态接口进行访问。

根据上述五种类型数据以及对应的存储位置、访问方式，可以形成以下表格，如表一所示：

表一

根据上述不同数据的访问方式的不同，主控板与业务板的通信方式可以包括以下几种方式：

第一种通信方式：主控板用户态与业务板用户态通信

传输数据：软件版本文件信息，对应表一中的第二种数据；

应用场景：用户通过WEB页面或命令行给业务板下发软件版本文件或读取软件版本文件信息时，使用这种通信方式。对应上述第二种情况。

接口类型：使用标准的用户态网络编程接口进行通信(用户态接口)。

第二种通信方式：主控板内核态与业务板用户态通信

一体化分布式网关设备中暂无这种应用，此处不作讨论。

第三种通信方式：主控板用户态与业务板内核态通信

传输数据：安全策略、转发表项；会话统计、流量统计、业务日志等信息；分别对应第一数据、第四数据。

应用场景：用户需要向业务板下发安全策略、转发表项，对应第三种情况；或者从业务板获取会话统计、流量统计、业务日志等信息时，对应第四种情况，一般为主控板用户态与业务板内核态之间通信。

接口类型：主控板的内核态接口、业务板的内核态接口

第四种通信方式：主控板内核态与业务板内核态通信：

传输数据：主控板学习到的动态MAC表项、ARP表项、路由表项，对应表一中的第一数据；业务板在业务处理时产生的系统日志、业务日志等信息，对应表一中的第四数据；

应用场景：主控板需要随时将自身学习到的动态MAC表项、ARP表项、路由表项等数据发送到业务板，业务板需要将自身产生的系统日志、业务日志等信息发送到主控板，此时一般为主控板内核态与业务板内核态之间通信。

接口类型：主控板的内核态接口、业务板的内核态接口

业务板内核态向主控板内核态发送数据，一般属于主控板用户态主动请求的情况，可以归入上述第三种通信方式。

由于上述第四种通信方式可以归为上述第三种通信方式，所以，在实际应用中，主要涉及两种通信方式：主控板用户态与业务板用户态之间的通信，对应上述第一种通信方式；和主控板用户态与业务板内核态之间的通信，对应上述第三种通信方式。

现有技术中，实现上述第三种板间通信方式的过程如图1所示，图1示出了现有技术主控板用户态从业务板内核态读取数据的示意图，包括：主控板用户态客户端进程建立socket连接，发起请求；请求数据通过标准网络协议栈进入主控板内核态，封装为标准网络报文，通过查找路由表项找到出口即主控板上与业务板相连的内部口并发包；业务板上与主控板相连的内部口收到报文，进入业务板内核态标准网络协议栈，在内核中解析成数据块并上送到业务板用户态服务器进程；业务板用户态服务器进程收到请求后，通过系统调用等方式切换到业务板内核态，在业务板内核态将主控板需要读取的信息写入缓冲区，并返回到业务板用户态；业务板用户态进程从内核取得数据，由网络编程标准接口切换到业务板内核态，封装成应答报文，通过查找路由表项找到出口即业务板与主控板相连的内部口并发包；主控板上与业务板相连的内部口收到报文，进入主控板内核态标准网络协议栈，在内核中解析成数据块并上送到用户态客户端进程，由该进程组织数据格式，发送到WEB页面或命令行终端。

在这一过程中，系统需要分别在主控板、业务板的用户态/内核态间反复切换，虽然大部分过程都封装在标准网络通信流程中，但数据反复传送和重新组织，不仅拉长了处理流程，容易引入错误，而且造成CPU和通道繁忙，对系统性能造成不良影响。

鉴于现有技术的上述缺陷，本发明提供了一种新的实现主控板用户态从业务板内核态读取数据的方法。本发明实施例在实现上述第三种板间通信方式，采用了三种通信机制，实现从主控板用户态程序实时、高效读取业务板内核态数据。

首先，介绍操作系统的用户态和内核态。内核态与用户态是操作系统的两种运行级别。

在内核态下，CPU可执行任何指令，CPU可以访问内存所有数据，包括外围设备，例如硬盘、网卡。CPU也可以将自己从一个程序切换到另一个程序。

在用户态下，CPU只能执行非特权指令，CPU只能受限的访问内存，且不允许访问外围设备，占用CPU的能力被剥夺，CPU资源可以被其他程序获取。

当CPU处于内核态，可以随意进入用户态；而当CPU处于用户态时，用户从用户态切换到内核态只有在系统调用和中断两种情况下发生，一般程序一开始都是运行于用户态，当程序需要使用系统资源时，就必须通过调用软中断进入内核态。

下面介绍本发明方法实施例采用的三种通信机制，包括：

第一种通信机制：Conplat系统调用

系统调用是LINUX系统常用于用户态和内核态通信的机制，只能由用户态主动发起，可用于用户态向内核态发送数据，或用户态从内核态读取数据，但不能用于内核态主动向用户态发送数据。

本发明实施例采用的系统调用技术为基于LINUX系统的Conplat系统调用技术，该技术在LINUX原生系统调用技术上作了改进，支持以下参数：

(1)模块ID：标识不同的业务模块，比如接口管理模块的模块ID为1，会话管理模块的模块ID为2。某模块的用户态程序执行系统调用时，切换到内核态，由内核态相应的处理接口进行处理。

(2)通信类型：标识本次系统调用是下发到本机还是下发到业务板，比如，当本次系统调用是下发到本机时，可以用代码0表示；当本次系统调用是下发到某一业务板时，可以用该业务板对应的业务板槽号作为通信类型代码表示该系统调用。

(3)业务板槽号：当通信类型代码表示本次系统调用是下发到业务板时，本参数标识本次系统调用是下发到哪块业务板。

(4)操作类型：分为只读、只写和读写三种类型。只读是指本次系统调用不向内核态传送数据，只从内核态向用户态传送数据，用于用户态程序不加条件地从内核态读取指定数据，比如路由管理模块读取系统当前的路由表项数；只写是指本次系统调用只向内核态传送数据，而不从内核态读取数据，用于用户态程序向内核态下发配置，比如接口管理模块将网络接口启用或禁用；读写是指既向内核态传送数据，又从内核态向用户态传送数据，一般用于用户态程序指定条件读取内核态数据，比如路由管理模块从内核读取指定网络接口上的路由表项信息，需要将网络接口名传送至内核态，内核态处理程序再将相应接口的路由表项信息传送到用户态。本发明实施例中，涉及的操作类型为只读和读写两种情况，不涉及只写这种操作类型。

(5)模块操作码：与模块ID结合使用。每个模块都有多种系统调用操作，不同的系统调用操作对应唯一的模块操作码。比如接口管理模块要通过系统调用启用或禁用接口、创建或删除接口、给接口配置或删除IP地址等等，每个操作对应一个本模块唯一的操作码。

(6)模块数据：用户态程序向内核态或内核态向用户态传送的具体数据。比如接口管理模块要通过系统调用启用或禁用一个接口时，需要告知内核态处理程序要操作的接口的名称和状态标识(启用或禁用)，接口名和状态标识就作为本次系统调用的数据存放在本参数中。

(7)返回值：标识本次系统调用执行是否成功。

通过Conplat系统调用，各业务模块能够根据需要，灵活选择用户态程序与内核态程序的交互方式。主控板用户态程序使用Conplat系统调用能够向本板内核态程序下发配置或从本板内核态程序读取数据，或者向业务板内核态下发配置；业务板用户态程序使用Conplat系统调用能够向本板内核态程序下发配置或从其读取数据。

但是，由于主控板程序通过Conplat系统调用与业务板内核态程序交互时，是使用Conplat平台内核态板间通信机制，只能单向通信，所以主控板用户态程序不能使用Conplat系统调用从业务板内核态程序读取数据。

第二种通信机制：LINUX netlink通信机制

netlink机制也是LINUX系统中常用于用户态和内核态通信的机制，其使用标准socket接口进行实现，既可由用户态主动发起也可由内核态主动发起，一般用于由内核态主动向用户态发送数据。

相比系统调用来说，LINUX netlink通信机制的实现方式和控制机制更复杂，故障点更多，因此一般不用于取代系统调用从用户态主动发起和内核态的通信。

第三种通信机制：内核态板间通信机制

内核态板间通信机制，采用自定义的报文格式封装数据。发送方只需将所需发送的数据写入缓冲区，并指定接收方槽位号、模块ID、操作类型命令字等基本信息即可，通信框架根据这些基本信息将报文发送到相应槽位的业务板，调用相应模块的处理函数，即完成了一次通信过程。

内核态板间通信机制的特点是相关流程在内核态软中断上下文中运行，不能长时间等待、造成内核态阻塞。

如果板间通信时，发送方发完消息后等待对方回应，则会严重降低板间通信的实时性，而且可能由于对方处理错误、不处理或通道拥塞等情况导致收不到回应而长时间阻塞，造成系统崩溃。因此，内核态板间通信机制只在需要确保对方已收到消息的场景下实现了确认机制，但并不支持发送请求后等待应答数据返回。因此，本发明实施例在一体化分布式设备中，当主控板内核态程序与业务板卡内核态程序间互相发送数据时，一般使用该板间通信机制。

基于上述三种通信机制，本发明实施例提供了一种主控板与业务板间传输数据的方法，采用该方法可以实现主控板用户态程序直接高效、实时地从业务板内核态程序读取数据。

参照图2所示的本发明主控板与业务板间传输数据的方法实施例一的流程图，在主控板侧，主控板的操作系统可以在用户态和内核态之间切换，上述方法包括以下步骤：

步骤11、获取用户请求数据；

参照图3所示的步骤11具体实施方式的流程图，步骤11可以具体包括：

步骤111、接收用户请求；

用户通过WEB页面或命令行终端进行操作，输入用户请求。对应地，主控板的某一模块根据用户的输入产生相应的请求数据，并将该请求数据交给主控板的用户态程序。

比如，当用户需要获取2号槽业务板的数据时，该数据可以是会话信息、流量统计信息等，通过设备WEB页面或命令行终端进行操作，产生一个相应的请求，该请求被交给主控板用户态程序。

假设上述请求是：从WEB页面查看2号业务板槽对应的第2业务板中流量最大的前10条会话信息。

步骤112、根据所述用户请求组织目标数据；该目标数据为调用Conplat系统调用需要的数据，至少包括：通信类型、业务板槽号、操作类型；

其中，上述通信类型可以包括：主控板用户态与内核态之间的通信，可以将代码设置为0；和，主控板用户态与业务板之间的通信，可以将代码设置为对应的业务板槽号。

业务板槽号为：一体化分布式网关设备中插接各个业务板的卡槽的编号。

操作类型可以包括：读和/或写，即包括：读操作、写操作、读和写操作。

对应上述实例，上述目标数据包括以下参数：

1)业务板槽号为：2；

2)通信类型为：主控板用户态与业务板之间的通信；

3)操作类型为：读操作，即从主控板到业务板的读操作；

还包括以下参数：

4)模块ID：用户请求对应模块的ID，即会话管理模块ID；

5)模块操作码：表示获取会话topN信息的操作码；

6)模块数据：要获取的会话条数N，本示例中N等于10。

步骤113、将上述目标数据按照预设数据格式封装为用户请求数据。步骤12、通过系统调用通信机制将所述用户请求数据发送到内核态；

本发明实施例中，步骤12可以具体为：主控板用户态程序通过Conplat系统调用将上述用户请求数据发送至主控板内核态。

步骤13、通过内核态板间通信机制将所述用户请求数据对应的用户请求报文发送给对应业务板的内核态程序，以使所述业务板的内核态程序组织相应的应答数据，并将该应答数据发送给主控板内核态，由主控板内核态通过netlink客户端传输到主控板用户态程序；

参照图4所示的步骤13具体实施方式的流程图，上述步骤13可以包括：

步骤131、内核态程序从所述用户请求数据中解析业务板槽号；

通过解析上述业务板槽号，获知需要将上述用户请求数据发往哪个业务板，本示例中，获知业务板槽号为2。

步骤132、将所述用户请求数据按照板间通信机制所需报文格式封装成用户请求报文；步骤133、通过内核态板间通信机制将所述用户请求报文发送给所述业务板槽号对应业务板的内核态程序，以使所述业务板内核态程序根据相应请求组织相应的应答数据；

本示例中，主控板内核态程序通过内核态板间通信机制将上述用户请求报文发送给2号槽插接的第2业务板。

对应的，业务板内核态程序接收到主控板内核态发来的用户请求报文后，解析模块ID、模块操作码、模块数据等信息，组织相应的数据，打上板间系统调用标记，形成准备回应给主控板内核态的应答数据。

步骤134、系统调用返回到用户态程序。即，conplat系统调用从主控板内核态程序返回到用户态程序。

在本实施例的步骤134中，Conplat系统调用可以对流程中可能出错的步骤作出判断和保护，比如假设步骤133中的板间通信失败，比如业务板突然故障导致无法通信，则系统调用返回失败并设置相应的返回值，用户态程序获取到该返回值后，即可进行相应的出错处理。

步骤14、查询所述用户请求数据中的操作类型，当所述操作类型为读操作时，建立用于监听主控板内核态消息的netlink服务端；

参照图5所示的步骤14具体实施方式的流程图，上述步骤14可以包括：

步骤141、从所述目标数据中查询业务板槽号和操作类型；

主控板Conplat系统调用从内核态返回到用户态后，检查上述目标数据中的通信类型和操作类型；

步骤142、判断所述操作类型是否为读操作；该读操作表示从所述业务板槽号对应的业务板中读取数据；

Conplat系统调用从主控板内核态返回到用户态后，从所述目标数据中检查通信类型及操作类型，若所述操作类型为：发往业务板的读操作，即数据传输方向为从相应业务板读取数据，执行步骤143；若否，执行步骤144。

步骤143、若所述操作类型为读操作，则建立netlink服务端，以使所述netlink服务端监听主控板内核态消息；上述读操作包括：只读操作或读写操作。

结合示例，若目标数据中的相关信息表示：需要从第2业务板读取数据，则主控板用户态程序的Conplat系统调用建立netlink服务端。该netlink服务端用于监听主控板内核态消息，等待内核态回应消息。

netlink服务端等待主控板内核态回应消息时，主控板用户态程序被阻塞，直到netlink服务端接收到消息为止。即，conplat系统调用从内核态返回后，直到netlink服务端接收到应答数据之前，主控板用户态程序一直处于阻塞状态。

步骤144、若所述操作类型不是读操作，则Conplat系统调用返回到用户态程序。

在本发明另一优选实施例中，该步骤14还可以包括：

步骤A、设置所述netlink服务端等待内核态消息的时间阈值；

具体为，在conplat-syscall函数中增加一个参数，用于设置上述netlink服务端等待内核态消息的期限，该期限用一个时间阈值表示；

上述参数为空时，表示永久等待；上述参数为0时，表示不等待；上述参数非空且非0时，表示等待期限，该期限的时间单位可以是秒或微秒等。

步骤B、若netlink服务端等待内核态消息的时间达到上述时间阈值后仍未获取到应答数据，则返回失败信息。后续可以由用户态程序进行相应的错误处理。

本发明实施例，为了防止因异常原因导致用户态程序被永久阻塞，Conplat系统调用指定了其中netlink服务端监听等待内核消息的期限，当Conplat系统调用中的netlink服务端等待时间达到期限而未能获取到消息时，返回失败信息，由用户态程序进行相应错误处理。

步骤15、接收来自业务板内核态的数据，通过netlink客户端将应答数据发送给用户态程序的所述netlink服务端；

步骤15具体为:当主控板内核态程序接收到来自业务板内核态的板间系统调用数据时，通过netlink客户端将所述数据发送给用户态程序的所述netlink服务端。

下面结合上述实例说明上述应答数据的获取过程：业务板内核态程序接收到主控板内核态发来的用户请求数据后，解析模块ID、模块操作码、模块数据。通过上述解析信息判断出该请求是要读取流量最大的前10条会话的信息，于是组织数据，即流量最大的前10条会话的信息，包含每条会话信息的特征和当前流量大小，经内核态板间通道发送给主控板内核态程序。该数据还携带了一个“板间系统调用”标记，表示该数据是主控板通过Conplat系统调用从业务板获取的应答数据，以和其它板间通信数据区分开。

参照图6所示的步骤15具体实施方式的流程图，上述步骤15可以包括：

步骤151、接收所述业务板通过内核态板间通信机制返回的数据；

具体为：主控板内核态程序接收所述业务板通过内核态板间通信机制发送的数据；

步骤152、判断上述数据中是否包含板间系统调用标记；

该步骤152为主控板内核态程序判断接收到的数据是否为用户通过Conplat系统调用请求的所需数据，即应答数据。

上述板间系统调用标记可以是一个自定义代码字段，也可以是“板间系统调用”对应编码。

即主控板内核态程序接收到业务板内核态发送的数据之后，判断该数据是否有板间系统调用标记，若有，则表示接收的数据为主控板通过Conplat系统调用从业务板获取的数据，即表示上述应答数据为用户需要的数据，执行步骤153；若无，则执行步骤154，结束流程。

步骤153、若所述应答数据中包含板间系统调用标记，表示该数据为上述用户请求的应答数据，则通过netlink客户端将所述应答数据发送给所述netlink服务端；

即若上述应答数据中包含有板间系统调用标记，表示该应答数据是主控板用户态程序请求的数据，则主控板内核态程序的netlink客户端将上述应答数据发送给主控板用户态程序的netlink服务端。

步骤154、若所述应答数据中不包含板间系统调用标记，表示该数据不是上述用户请求的应答数据，结束流程。

步骤16、所述netlink服务端接收到所述应答数据后，返回到用户态程序；具体为：主控板用户态程序接收Conplat系统调用中建立的netlink服务端接收到来自主控板内核态的应答数据后，返回到用户态程序。

即，主控板用户态程序接收到来自内核态的数据，从Conplat系统调用中返回，解除阻塞状态。

步骤17、所述用户态程序解析所述应答数据，组织成用户理解的形式并呈现给所述用户。

步骤17具体为：用户态程序解析上述应答数据，组织成用户可理解的形式，并通过WEB页面或命令行终端呈现给用户。

参照图7所示的本发明主控板与业务板间传输数据的方法实施例二的流程图，在图2所示的基础上还可以包括：

步骤10、系统初始化时，主控板内核态程序建立面向主控板用户态的netlink客户端，以使所述netlink客户端在监听到来自业务板内核态的消息后，将所述消息发送给主控板的用户态程序。

具体地，一体化分布式网关设备进行系统初始化时，主控板在内核态建立面向主控板用户态的netlink客户端。netlink客户端用于监听来自业务板内核态的消息。该消息包括上述步骤153中标记有板间系统调用的应答数据。

综上，按照以上流程，主控板用户态程序需要从业务板内核态读取信息时，只需一去一回，主控板用户态程序切换到内核态程序再切换回来，业务板则完全无需切换。虽然内核态程序发送和接收数据是异步操作，但实现了同步的效果，而主控板内核态、业务板内核态均未被阻塞，只有主控板用户态程序被阻塞。

为了防止因异常原因导致用户态程序被永久阻塞，Conplat系统调用指定了netlink服务端等待内核态消息的期限，当Conplat系统调用中的netlink服务端等待内核态回应消息的时间达到预设期限而未能获取到消息时，返回失败，由调用者进行相应错误处理。

相应的，参照图8，示出了本发明主控板与业务板间传输数据的方法实施例的流程图，应用于一体化分布式网关设备的业务板中，包括：

步骤21、接收主控板内核态通过内核态板间通信机制发送的用户请求报文；

步骤22、解析所述用户请求报文中的操作类型、模块操作码、模块数据信息，组织所述信息对应的数据，并为所述数据作上板间系统调用标记，形成应答数据；

步骤23、将所述应答数据通过所述内核态板间通信机制发送给主控板内核态程序。

本发明实施例在业务板侧描述了业务板内核态接收用户请求报文、解析请求报文数据、组织应答数据，并上述应答数据通过内核态板间通信机制发送给主控板内核态，以使主控板内核态程序调用的Conplat系统调用中建立的netlink客户端接收上述应答数据后，将含有板间系统调用标记的应答数据发送给用户态程序的netlink客户端；主控板用户态程序接收到来自内核态的数据后，从Conplat系统调用中返回，解除阻塞状态，将数据组织成用户可见格式呈现到WEB页面或命令行终端。

参照图9，示出了本发明主控板与业务板间传输数据的方法的示意图，如图9所示，包括：

步骤800、系统初始化时，主控板内核态程序建立面向主控板用户态的netlink客户端；

步骤801、netlink客户实时监听来自业务板的数据，本发明实施例中，主要用于监听来自业务板内核态的消息；以便在监听到来自业务板内核态的消息后，将所述消息发送给主控板的用户态程序。

步骤802、主控板用户态程序接收用户请求，组织conplat系统调用需要的数据，称之为目标数据，将上述目标数据封装为用户请求数据；

步骤803、通过conplat系统调用通信机制将上述用户请求数据发送给主控板内核态程序；

步骤804、主控板内核态程序检查上述用户请求数据中的通信类型，若通信类型对应的代码为业务板槽号，则表示上述用户请求数据需要发往对应的业务板；

步骤805、主控板内核态通过内核态板间通信机制将上述用户请求数据对应的用户请求报文发送给业务板内核态程序；

步骤806、conplat系统调用返回到用户态程序；

步骤807、用户态conplat系统调用检查目标数据中的操作类型，如是发往业务板的读操作，则在用户态conplat系统调用中建立netlink服务端；

步骤808、netlink服务端实时监听来自主控板内核态的消息；

步骤809、业务板内核态接收到用户请求报文后，根据用户请求组织对应的数据形成应答报文，并将应答数据的数据类型标记为“板间系统调用”；

步骤810、业务板内核态通过内核态板间系统调用通信机制将所述应答报文发送给主控板内核态；

步骤811、主控板内核态接收来自业务板内核态的数据，判断上述数据的数据类型是否为：板间系统调用；

步骤812、主控板内核态的netlink客户端将标记有“板间系统调用”的数据发送给主控板用户态的netlink服务端；

步骤813、netlink服务端接收到来自内核的应答数据，从conplat系统调用中返回到用户态程序，组织数据格式发送到WEB页面或命令行终端。

由此可见，本发明实施例将Conplat系统调用、Conplat平台内核态板间通信机制和LINUX netlink通信机制结合起来，以内嵌了内核态板间通信机制的Conplat系统调用为主体，通过netlink机制解决Conplat系统调用不能从内核态主动发起的问题，实现了主控板用户态程序直接从业务板内核态程序获取数据，而不经过业务板用户态程序。

采用本发明实施例提供的板间通信方法，在一体化分布式网关设备中实现了从主控板用户态程序直接从业务板内核态程序读取数据，相对于图1所示现有技术的实现方式，不再使用标准socket编程机制，无需业务板用户态程序参与，有效减少了主控板进程和业务板进程在用户态/内核态间切换次数，并减少了数据传输次数减，有效缩短了数据传输路径，减少了故障点，提高了系统性能和实时性，改善了系统稳定性和用户体验。

另外，将板间通信过程封装在Conplat系统调用中，各业务模块可通过该编程接口简洁地实现跨板请求数据，无须各模块自行实现相关流程，因而降低了编程复杂度和出错概率。

对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员用该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。

其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本发明所必须的。

对应上述方法实施例，本发明提供了一种主控板与业务板间传输数据的装置，设置于一体化分布式网关设备的主控板中。

参照图10所示的本发明主控板与业务板间传输数据的装置实施例一的结构框图，包括：

用户请求获取模块91，用于获取用户请求数据；

参照图11所示本发明实施例中用户请求获取模块的结构框图，用户请求获取模块91可以包括：

请求接收单元911，用于接收用户请求；

目标数据组织单元912，用于根据所述用户请求组织目标数据，所述目标数据至少包括：通信类型、业务板槽号、操作类型；

数据封装单元913，用于将所述目标数据按照预设数据格式封装为用户请求数据。

第一发送模块92，用于通过系统调用通信机制将所述用户请求数据发送到内核态；

第二发送模块93，用于通过内核态板间通信机制将所述用户请求数据对应的用户请求报文发送给对应业务板的内核态程序，以使所述业务板的内核态程序组织相应的应答数据，并将所述应答数据传输到主控板的用户态程序；

参照图12所示本发明实施例中第二发送模块的结构框图，第二发送模块93包括：

第一查询单元931，用于从所述用户请求数据中解析业务板槽号；

封装单元932，用于将所述用户请求数据按照板间通信机制所需报文格式封装成用户请求报文；第二发送单元933，用于通过内核态板间通信机制将所述用户请求报文发送给所述业务板槽号对应业务板的内核态程序，以使所述业务板内核态程序组织相应的应答数据；

第一返回单元934，用于所述系统调用返回到用户态程序。

netlink服务端建立模块94，用于查询所述用户请求数据中操作类型，当所述操作类型为读操作时，建立用于监听主控板内核态消息的netlink服务端；

参照图13所示本发明实施例中netlink服务端建立模块的结构框图，netlink服务端建立模块94可以包括：

第二查询单元941，用于从所述目标数据中查询业务板槽号和操作类型；

第一判断单元942，用于判断所述操作类型是否为表示从所述业务板槽号对应的业务板读取数据的读操作；

netlink服务端建立单元943，用于在所述操作类型为读操作的情况下，建立netlink服务端，以使所述netlink服务端监听主控板内核态消息；

第二返回单元944，用于在所述操作类型不是读操作的情况下，返回到用户态程序。

参照图14所示本发明实施例中netlink服务端建立模块的另一结构框图，在图12所示实施例的基础上，还可以包括：

等待期限设置单元945，用于设置所述netlink服务端等待内核消息的时间阈值；

信息提示单元946，用于在所述netlink服务端等待内核消息的时间达到所述时间阈值后未获取到应答数据的情况下，返回失败信息。

第三发送模块95，用于接收来自业务板内核态的数据，通过netlink客户端将应答数据发送给用户态程序的所述netlink服务端；

参照图15所示本发明实施例中第三发送模块的结构框图，第三发送模块95可以包括：

接收单元951，用于接收所述业务板通过内核态板间通信机制返回的数据；

第二判断单元952，用于判断所述数据中是否包含板间系统调用标记；

第三发送单元953，用于在所述答数据中包含板间系统调用标记的情况下，通过netlink客户端将应答数据发送给所述netlink服务端，以使所述netlink服务端接收到所述应答数据后返回到用户态程序；

结束单元954，用于在所述数据中不包含板间系统调用标记的情况下，结束流程。

接收模块96，用于在所述netlink服务端接收到所述应答数据后，返回到用户态程序；

反馈模块97，用于所述用户态程序解析所述应答数据，组织成用户理解的形式并呈现给所述用户。

参照图16所示本发明主控板与业务板间传输数据的装置实施例二的结构框图，在图10所示实施例的基础上，还可以包括：

netlink客户端建立模块90，用于在系统初始化时，主控板内核态程序建立面向主控板用户态的netlink客户端，以使所述netlink客户端在监听到来自业务板内核态的消息后，将所述消息发送给主控板的用户态程序。

对应上述业务板侧的方法实施例，本发明还提供了一种主控板与业务板间传输数据的装置，设置于一体化分布式网关设备的业务板中。

参照图17所示本发明主控板与业务板间传输数据的装置实施例的结构框图，所述装置包括：

接收模块101，用于接收主控板内核态通过内核态板间通信机制发送的用户请求报文；

数据组织模块102，用于解析所述用户请求报文中的操作类型、模块操作码、模块数据信息，组织所述信息对应的数据，并为所述数据作上板间系统调用标记，形成应答数据；

发送模块103，用于将所述应答数据通过所述内核态板间通信机制发送给主控板内核态程序。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (16)

1.一种主控板与业务板间传输数据的方法，其特征在于，应用于一体化分布式网关设备的主控板中，所述方法包括：

获取用户请求数据；

通过系统调用通信机制将所述用户请求数据发送到内核态；

通过内核态板间通信机制将所述用户请求数据对应的用户请求报文发送给对应业务板的内核态程序，以使所述业务板的内核态程序组织相应的应答数据，并将所述应答数据传输到主控板的用户态程序；

查询所述用户请求数据中的操作类型，当所述操作类型为读操作时，建立用于监听主控板内核态消息的netlink服务端；

接收来自业务板内核态的数据，通过netlink客户端将应答数据发送给用户态程序的所述netlink服务端；

所述netlink服务端接收到所述应答数据后，将所述应答数据返回到用户态程序；

所述用户态程序解析所述应答数据，组织成用户理解的形式并呈现给所述用户。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

系统初始化时，主控板内核态程序建立面向主控板用户态的netlink客户端，以使所述netlink客户端在监听到来自业务板内核态的消息后，将所述消息发送给主控板的用户态程序。

3.根据权利要求1所述的方法，其特征在于，所述获取用户请求数据，包括：

接收用户请求；

根据所述用户请求组织目标数据，所述目标数据至少包括：通信类型、业务板槽号、操作类型；

将所述目标数据按照预设数据格式封装为用户请求数据。

4.根据权利要求1所述的方法，其特征在于，所述通过内核态板间通信机制将所述用户请求数据对应的用户请求报文发送给对应业务板的内核态程序，以使所述业务板内核态程序组织相应的应答数据，返回到用户态程序，包括：

从所述用户请求数据中解析业务板槽号；

将所述用户请求数据按照板间通信机制所需报文格式封装成用户请求报文；

通过内核态板间通信机制将所述用户请求报文发送给所述业务板槽号对应业务板的内核态程序，以使所述业务板内核态程序组织相应的应答数据；

所述系统调用返回到用户态程序。

5.根据权利要求3所述的方法，其特征在于，所述查询所述用户请求数据中的操作类型，当所述操作类型为读操作时，建立用于监听主控板内核态消息的netlink服务端；包括：

从所述目标数据中查询业务板槽号和操作类型；

判断所述操作类型是否为表示从所述业务板槽号对应的业务板中读取数据的读操作；

若所述操作类型为读操作，则建立netlink服务端，以使所述netlink服务端监听主控板内核态消息；

若所述操作类型不是读操作，则返回到用户态程序。

6.根据权利要求1所述的方法，其特征在于，所述接收到来自业务板内核态的数据，通过netlink客户端将应答数据发送给用户态程序的所述netlink服务端；包括：

接收所述业务板通过内核态板间通信机制返回的数据；

判断所述数据中是否包含板间系统调用标记；

若所述数据中包含板间系统调用标记，表示该数据为应答数据，通过netlink客户端将所述应答数据发送给所述netlink服务端；

若所述应答数据中不包含板间系统调用标记，表示该数据不是应答数据，结束流程。

7.根据权利要求5所述的方法，其特征在于，所述方法还包括：

设置所述netlink服务端等待内核态消息的时间阈值；

若所述netlink服务端等待内核态消息的时间达到所述时间阈值后未获取到应答数据，则返回失败信息。

8.一种主控板与业务板间传输数据的方法，其特征在于，应用于一体化分布式网关设备的业务板中，所述方法包括：

接收主控板内核态通过内核态板间通信机制发送的用户请求报文；

解析所述用户请求报文中的操作类型、模块操作码、模块数据信息，组织所述信息对应的数据，并为所述数据作上板间系统调用标记，形成应答数据；

将所述应答数据通过所述内核态板间通信机制发送给主控板内核态程序。

9.一种主控板与业务板间传输数据的装置，设置于一体化分布式网关的主控板中，其特征在于，所述装置包括：

用户请求获取模块，用于获取用户请求数据；

第一发送模块，用于通过系统调用通信机制将所述用户请求数据发送到内核态；

第二发送模块，用于通过内核态板间通信机制将所述用户请求数据对应的用户请求报文发送给对应业务板的内核态程序，以使所述业务板的内核态程序组织相应的应答数据，并将所述应答数据传输到主控板的用户态程序；

netlink服务端建立模块，用于查询所述用户请求数据中操作类型，当所述操作类型为读操作时，建立用于监听主控板内核态消息的netlink服务端；

第三发送模块，用于接收来自业务板内核态的数据，通过netlink客户端将应答数据发送给用户态程序的所述netlink服务端；

接收模块，用于在所述netlink服务端接收到所述应答数据后，将所述应答数据返回到用户态程序；

反馈模块，用于所述用户态程序解析所述应答数据，组织成用户理解的形式并呈现给所述用户。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括：

netlink客户端建立模块，用于在系统初始化时，主控板内核态程序建立面向主控板用户态的netlink客户端，以使所述netlink客户端在监听到来自业务板内核态的消息后，将所述消息发送给主控板的用户态程序。

11.根据权利要求9所述的装置，其特征在于，所述用户请求获取模块，包括：

请求接收单元，用于接收用户请求；

目标数据组织单元，用于根据所述用户请求组织目标数据，所述目标数据至少包括：通信类型、业务板槽号、操作类型；

数据封装单元，用于将所述目标数据按照预设数据格式封装为用户请求数据。

12.根据权利要求9所述的装置，其特征在于，所述第二发送模块包括：

第一查询单元，用于从所述用户请求数据中解析业务板槽号；

封装单元，用于将所述用户请求数据按照板间通信机制所需报文格式封装成用户请求报文；

第二发送单元，用于通过内核态板间通信机制将所述用户请求报文发送给所述业务板槽号对应业务板的内核态程序，以使所述业务板内核态程序组织相应的应答数据；

第一返回单元，用于所述系统调用返回到用户态程序。

13.根据权利要求11所述的装置，其特征在于，所述netlink服务端建立模块，包括：

第二查询单元，用于从所述目标数据中查询业务板槽号和操作类型；

第一判断单元，用于判断所述操作类型是否为表示从所述业务板槽号对应的业务板读取数据的读操作；

netlink服务端建立单元，用于在所述操作类型为读操作的情况下，建立netlink服务端，以使所述netlink服务端监听主控板内核态消息；

第二返回单元，用于在所述操作类型不是读操作的情况下，返回到用户态程序。

14.根据权利要求9所述的装置，其特征在于，所述第三发送模块包括：

接收单元，用于接收所述业务板通过内核态板间通信机制返回的数据；

第二判断单元，用于判断所述数据中是否包含板间系统调用标记；

第三发送单元，用于在所述数据中包含板间系统调用标记的情况下，通过netlink客户端将应答数据发送给所述netlink服务端；

结束单元，用于在所述数据中不包含板间系统调用标记的情况下，结束流程。

15.根据权利要求13所述的装置，其特征在于，所述netlink服务端建立模块还包括：

等待期限设置单元，用于设置所述netlink服务端等待内核消息的时间阈值；

信息提示单元，用于在所述netlink服务端等待内核消息的时间达到所述时间阈值后未获取到应答数据的情况下，返回失败信息。

16.一种主控板与业务板间传输数据的装置，其特征在于，设置于一体化分布式网关设备的业务板中，所述装置包括：

接收模块，用于接收主控板内核态通过内核态板间通信机制发送的用户请求报文；

数据组织模块，用于解析所述用户请求报文中的操作类型、模块操作码、模块数据信息，组织所述信息对应的数据，并为所述数据作上板间系统调用标记，形成应答数据；

发送模块，用于将所述应答数据通过所述内核态板间通信机制发送给主控板内核态程序。