设备驱动消息处理方法及装置的制作方法

文档序号:6430950阅读:124来源:国知局
专利名称:设备驱动消息处理方法及装置的制作方法
技术领域
本发明涉及通信领域,具体而言,涉及一种设备驱动消息处理方法及装置。
背景技术
基于全球无线芯片的格局,不同的厂商均在推出不同的设备驱动规范,例如,高通和微软主推的网络驱动接口规范(network driver interface spec,简称为NDIS) +高通 MSM接口(Qualcomm MSM hterface,简称为QMI)的移动宽带设备高速接入方案成为当下移动宽带设备的主流接入方式之一;但NDIS+QMI的方式目前在windows系统上得到了应用,并且,对于其他的系统,随着技术的不断发展,逐步的也可以支持该规范。同时,对于操作系统而言,其也在不断推新,一方面,现有的操作系统在不停的发展以适应不同的终端类型,另一方面,也出现了其他类型的新的操作系统,例如,安卓 Android移动操作系统。由上述现有的技术发展的趋势可以看出,操作系统与设备驱动规范的发展并不是统一的,这样,操作系统需要支持原来越多的设备驱动,对于不同的设备驱动,在操作系统上均需要编写对应的与上层应用对接的中间层代码。即在现有技术中,操作系统对设备驱动的兼容性比较差。

发明内容
本发明的主要目的在于提供一种设备驱动消息处理方法及装置,以至少解决上述问题。根据本发明的一方面,提供了一种设备驱动消息处理方法,包括如下步骤通过提供给上层协议的第一接口,与所述上层协议对应的上层进行消息的传输;将来自所述上层协议的消息按照设备驱动所支持的协议进行封装,并且,将来自所述设备驱动的消息使用所述设备驱动所支持的协议将该消息解封装为所述上层协议所支持的消息格式;通过提供给所述设备驱动的第二接口,与所述设备驱动传输消息,其中,该消息的格式为所述设备驱动所支持的协议的格式。优选地,在通过所述第一接口进行传输的消息中携带有设备标识的情况下,通过所述第二接口与所述设备驱动传输消息包括,根据所述设备标识通过所述第二接口将携带有该设备标识的消息发送给与所述设备标识对应的设备驱动。优选地,还包括对通过所述设备驱动接入的设备进行状态检测和管理。优选地,所述设备驱动为NDIS设备驱动,和/或,所述上层协议为RIL。根据本发明的另一方面,提供了一种设备驱动消息处理装置,包括第一传输模块,用于通过提供给上层协议的第一接口,与所述上层协议对应的上层进行消息的传输;消息处理模块,用于将来自所述上层协议的消息按照设备驱动所支持的协议进行封装,并且, 将来自所述设备驱动的消息使用所述设备驱动所支持的协议将该消息解封装为所述上层协议所支持的消息格式;第二传输模块,用于通过提供给所述设备驱动的第二接口,与所述设备驱动传输消息,其中,该消息的格式为所述设备驱动所支持的协议的格式。优选地,所述第二传输模块,用于在通过所述第一接口进行传输的消息中携带有设备标识的情况下,根据所述设备标识通过所述第二接口将携带有该设备标识的消息发送给与所述设备标识对应的设备驱动。优选地,还包括设备管理模块,用于对通过所述设备驱动接入的设备进行状态检
测和管理。优选地,所述设备驱动为NDIS设备驱动,和/或,所述上层协议为RIL。通过本发明,采用通过提供给上层协议的第一接口,与所述上层协议对应的上层进行消息的传输;将来自所述上层协议的消息按照设备驱动所支持的协议进行封装,并且, 将来自所述设备驱动的消息按照所述设备驱动所支持的协议将该消息解封装为所述上层协议所支持的消息格式;通过提供给所述设备驱动的第二接口,与所述设备驱动传输消息, 其中,该消息的格式为所述设备驱动所支持的协议的格式,解决了现有技术中操作系统对设备驱动的兼容性比较差问题,提高了操作系统对设备驱动的兼容性。


此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中图1是根据本发明实施例的设备驱动消息处理方法的流程图;图2是根据本发明实施例的设备驱动消息处理装置的结构框图;图3是根据本发明实施例的Android系统的设备驱动的架构的示意图一;图4是根据本发明实施例的Android系统的设备驱动的架构的示意图二 ;图5是根据本发明实施例的下行数据传输的流程图;图6是根据本发明实施例的上行数据传输的流程图。
具体实施例方式下文中将参考附图并结合实施例来详细说明本发明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。在本实施例中提供了一种设备驱动消息处理方法,图1是根据本发明实施例的设备驱动消息处理方法的流程图,如图1所示,该流程包括如下步骤步骤S102,通过提供给上层协议的第一接口,与上层协议所对应的上层进行消息的传输;步骤S104,将来自该上层协议的消息按照设备驱动所支持的协议进行封装,并且, 将来自设备驱动的消息使用设备驱动所支持的协议将该消息解封装为上层协议所支持的消息格式;步骤S106,通过提供给设备驱动的第二接口,与设备驱动传输消息,其中,该消息的格式为设备驱动所支持的协议的格式。需要说明的是,上述的步骤不一定按照步骤S102至步骤S106的顺序执行。通过上述步骤,提供了在设备驱动层和上层协议之间提供了一种中间层的处理方式,这样,对于不同的驱动程序不需要再重新开发中间层的驱动,从而提高了操作系统对设备驱动的兼容性。为了同时支持多个设备驱动(例如,多个同类型的设备驱动),在一个优选实施方式中,可以在第一接口传输的消息中设置设备标识,在这种情况下,通过第二接口与设备驱动传输消息包括;根据设备标识通过第二接口将携带有该设备标识的消息发送给与设备标识对应的设备驱动。通过该优选的实施方式,将对多个设备的处理也移植到中间层中,不需要上层和设备驱动进行任何的改动,使对多个设备驱动的支持更好。优选地,在该中间层中还可以增加对通过设备驱动接入的设备进行状态检测和管理的功能。通过这些功能的增加可以更好的对设备驱动进行控制。在目前的安卓系统中,并没有提供能够对多个NDIS设备驱动的支持,上述实施例及优选的实施方式可以应用在安卓系统中,在该系统中为了较小的改动系统架构,上述的中间呈位于无线宽带业务处理(Radio Interface Layer,简称为RIL)(即上层协议中的一种)和设备驱动之间。这样可以实现与Android系统现有RIL驱动的无缝对接,从而既能实现对多NDIS设备的无缝接入,提高Android系统的对多NDIS设备支持的缺陷,扩展了 Android系统的功能,提供了 Android系统更为丰富的宽带设备接入,又能较少的修改 Android系统框架。在本实施例中还提供了一种设备接入处理装置,该装置用于实现上述实施例及优选实施方式,已经进行过说明的不再赘述。如以下所使用的,术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现,但是硬件,或者软件和硬件的组合的实现也是可能并被构想的。图2是根据本发明实施例的设备驱动消息处理装置的结构框图,如图2所示,该装置包括第一传输模块22、消息处理模块M 和第二传输模块26,下面对该装置涉及的模块进行说明。第一传输模块22,用于通过提供给上层协议的第一接口,与上层协议对应的上层进行消息的传输;消息处理模块对,连接至第一传输模块22,该模块用于将来自上层协议的消息按照设备驱动所支持的协议进行封装,并且,将来自设备驱动的消息按照设备驱动所支持的协议将该消息解封装为上层协议所支持的消息格式;第二传输模块沈,连接至消息处理模块M,该模块用于通过提供给设备驱动的第二接口,与设备驱动传输消息,其中, 该消息的格式为设备驱动所支持的协议的格式。优选地,第二传输模块22用于在通过第一接口进行传输的消息中携带有设备标识的情况下,根据设备标识通过第二接口将携带有该设备标识的消息发送给与设备标识对应的设备驱动。优选地,该装置还可以包括设备管理模块,该模块用于对通过设备驱动接入的设备进行状态检测和管理。下面以安卓系统为例,结合对NDIS设备驱动的支持对一个优选实施例进行说明。在优选实施例中,对于安卓系统如何支持NDIS单设备驱动并不是讨论的重点,而重点在于如何提供一个中间层的处理方式,以及如何支持多个NDIS设备。对于安卓系统如何支持NDIS设备可以采用不同的方式来进行,其并不影响本优选实施例的实施,在此不再赘述。本优选实施例可以对多NDIS设备进行支持,实现了与Android系统现有RIL驱动的无缝对接。图3是根据本发明实施例的Android系统的设备驱动的架构的示意图一,如图3所示,该驱动系统包括RIL框架、QMI/AT框架和设备驱动模块,其中,该QMI/AT框架包括 QmiClient模块304 (用于实现第一传输模块22的功能)、QmiDaemon模块302 (用于实现第二传输模块26和消息处理模块M的功能),当然,为了支持AT命令,还可以增加AT命令模块301。该QMI/AT框架实现了上述中间层的功能。图4是根据本发明实施例的Android系统的设备驱动的架构的示意图二,如图4 所示,在该架构中增加了消息处理模块403 (该消息处理模块和QmiDaemon模块结合实现了上述消息处理模块M的功能)和设备管理模块405。图4中的QmiDaemon模块402相对于图3中的QmiDaemon模块302也进行了修改,下面对此进行说明。QmiClient模块404,依旧提供同步的接口调用给上层使用,除了在接口中增加了设备ID外、依旧保持了 RIL层接口的统一性。消息处理模块403,主要负责消息的封装和解析,其中对来自RIL层消息按无线数据服务(QMI Wireless Data Service,简称为 WDS)、QMI 控制服务(QMI Control Service, 简称为CTL)、QMI数据管理服务(QMI Device Management krvice,简称为DMS)等消息格式进行数据封装,并将封装好的消息数据,通过socket机制发送出去,接收则通过在接收线程中等待从socket收到的数据,接收线程收到数据后,解析接收到数据,并通过设备ID、 消息ID等信息匹配是哪个请求消息的响应,对于主动上报的消息,则只需要确定设备ID即可。QmiDaemon模块402,主要负责消息的管理,异步发送和接收;消息的管理是指要接收来自消息处理模块通过socket发送过来的消息,之后根据消息所对应的设备ID,将该消息放到对应设备的发送消息队列中;接收线程中负责接收从设备读取的数据,并将接收到数据放在接收队列中。NDIS设备管理模块405,主要负责多个NDIS设备的节点管理,状态管理等。上述优选实施例提供的驱动方法及系统,具有以下优点(1)增加了对多个NDIS设备的支持,使得Android系统可以同时支持多个NDIS 设备,改变和扩展了现有Android系统中RIL驱动部分只能操作一个设备的情况,使得RIL 驱动部分可以增加对多个NDIS设备的支持、而RIL层之上的接口依旧保持不变,解决了 Android系统目前无法支持多个NDIS设备的问题。本优选实施例是将多NDIS设备的管理和接入方式融入到Android系统现有的RIL框架中,没有修改Android系统RIL和Framwork 的架构,增加了 Android系统对移动宽带设备的接入方式增加了 Android系统的扩展性;在 QmiDaemon模块中增加了对自定义消息处理的逻辑、使得本技术方案在Qmi协议之外可以增加对私有协议的支持,增强了 Android系统的扩展性。( NDIS设备作为后续移动宽带设备主流接入方式之一,可以一个系统上同时支持多个NDIS设备(例如不同制式的NDIS设备),极大地符合了后续多制式、多PDP设备的接入方式和技术的发展趋势,扩展了 Android系统的功能,使得Android系统有了更大的通用性,同时QMIClient模块对上层提供的接口依旧才用同步API的方式,兼容了以前的方案,使得上层对QMI Client的接口调用,不需要做过多的修改即可使用,大大的提高了本技术方案的通用性。下面上述图4中的模块进行详细的说明。QmiDaemon模块402,该模块可以通过如下三个线程完成
Qmi消息接收线程Qmi消息接收线程用于检测发送消息队列是否有消息需要处理,有则在此线程中调用NDIS设备管理模块封装的设备操作接口,将消息发送到对应的NDIS设备,如果发送成功,则通过消息邮箱(mail box)发送信号给响应消息处理线程,通知它发送ack ok的消息给消息处理模块,否则发送ack error消息;response消息则等待从NDIS设备的返回值; 如果是自定义消息类型,则直接处理,处理完成后,首先发送ack ok或者ack error的消息,然后直接发送response的消息内容给通过socket将结果发送给消息处理模块。NDIS设备数据接收线程NDIS设备数据接收线程用于检测是否有从NDIS设备来的数据需要处理,有则将接收到的消息和设备ID —起封装成预定义的格式,然后放进接收消息队列,同时通过消息邮箱(mail box)发送信号给响应消息处理线程,通知它发送响应(Response)消息给消息处理模块,否则继续循环检测。响应消息处理线程等待Qmi消息接收线程和NDIS设备数据接收线程发送过来的信号,根据信号类型分别处理如果是ack消息,则需要根据信号中携带的参数(设备ID和消息ID)匹配对应的消息请求,然后封装ACK消息,并通过socket发送消息给消息处理模块;如果是response 消息,同样需要根据设备ID和消息ID匹配对应的消息请求,然后封装response消息,并通过socket发送消息给消息处理模块;如果是主动上报的消息,仅仅匹配设备ID,然后封装主动上报的消息,并通过socket发送消息给消息处理模块。消息处理模块403该模块用来封装和解析消息;一是将来自QmiClient模块的消息根据内容的不同封装成为对应的QMI指令,例如,WDS、CTL、DMS等格式的NDIS报文数据,并通过socket发送给QmiDaemon模块;二是启动消息接收线程,通过socket接收来自QmiDaemon模块的ACK 消息、response消息和主动上报等响应消息;针对response消息需要根据WDS、CTL、DMS等格式解析响应消息内容,并通过设备ID、消息ID等信息匹配是哪个请求消息的响应,然后返回响应数据给QmiClient模块,对于主动上报的消息,则只需要确定设备ID即可。QmiClient 模块 404该模块主要负责提供同步的应用程序接口(Application Program hterface,简称为API)函数给上层调用,使得QMI和RIL可以无缝对接;原有系统中,RIL层的接口不需要设备ID即可直接发送消息和接收响应,现在有了多设备的管理,RIL层的接口需要增加设备ID,用来标识对不同设备的操作,因此在这里提供的API参数中增加了设备ID ;同时为了保持和以前接口的一致性和兼容性,接口的功能和业务上和原有系统基本保持一致, 仅仅增加了 NDIS设备特有的一些接口定义,例如获取网络接口名称(qmi_get_netWOrk_ interface一name) >(qmi_get_conn_duration)、NDIS i殳Ι profile 1 (qmi_profile_get)等。设备管理模块405该模块主要处理对于设备的状态检测和管理一是对设备的热插拔做出响应负责设备插入后,设备节点的注册和设备队列的维护,以及号量的初始化等;设备拔出后,设备节点队列的维护,设备状态信息的清理等;二是对设备操作API的封装,如打开、关闭、读、写等,这些操作接口类似于文件的操作;三是设备状态的维护,设备拔出等异常操作时, 设备状态的维护。下面结合图4对上行数据和下行数据的传输分别进行说明。图5是根据本发明实施例的下行数据传输的流程图,如图5所示,该流程包括如下步骤步骤S501,RIL层接收到Android系统的各种功能调用;步骤S502,根据不同的业务类型,调用QmiClient模块对应的接口 ;步骤S503,判断消息的类型,如果是CTL相关,则转往步骤S504 ;如果是WDS相关, 则转往步骤S505 ;如果是DMS相关,则转往步骤S506 ;步骤S504,根据CTL消息的格式,封装对应的CTL消息,封装完成后,转往步骤 S507 ;步骤S505,根据WDS消息的格式,封装对应的WDS消息,封装完成后,转往步骤 S507 ;步骤S506,根据DMS消息的格式,封装对应的DMS消息,封装完成后,转往步骤 S507 ;步骤S507,消息处理模块通过socket机制将封装好的数据发送出去;步骤S508,QmiDaemon模块接收来自sokcet的消息,收到消息后转往步骤S509 ;步骤S509,处理消息队列的维护;步骤S510,设备管理模块检测到消息队列有需要处理的消息,则通过设备操作接口对设备进行操作。图6是根据本发明实施例的上行数据传输的流程图,如图6所示,该流程包括如下步骤步骤S601,采用线程机制,启动设备数据读取线程。步骤S602,循环判断设备是否有数据,如果有数据则转入步骤S603处理,否则继续等待并检测消息。步骤S603,预先将收到的数据封装成固定的消息格式,然后放进消息队列。步骤S604,采用线程机制,预先启动Qmi消息接收线程。步骤S605,循环判断接收消息队列是否有数据,如果有,则转入步骤S606处理,否则继续等待并检测消息。步骤S606,解析从消息队列获取的消息。步骤S607,将解析后的消息通过socket机制发送。步骤S608,采用线程机制,预先启动socket消息接收线程。步骤S609,在socket检测线程中,循环检测是否有socket消息,如果有,则转入步骤S610处理,否则继续等待并检测消息。步骤S610,解析socket消息。步骤S611,将解析后的数据返回给RIL层接口。显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而可以将它们存储在存储装置中由计算装置来执行,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。 以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
权利要求
1.一种设备驱动消息处理方法,其特征在于包括如下步骤通过提供给上层协议的第一接口,与所述上层协议对应的上层进行消息的传输;将来自所述上层协议的消息按照设备驱动所支持的协议进行封装,并且,将来自所述设备驱动的消息使用所述设备驱动所支持的协议将该消息解封装为所述上层协议所支持的消息格式;通过提供给所述设备驱动的第二接口,与所述设备驱动传输消息,其中,该消息的格式为所述设备驱动所支持的协议的格式。
2.根据权利要求1所述的方法,其特征在于,在通过所述第一接口进行传输的消息中携带有设备标识的情况下,通过所述第二接口与所述设备驱动传输消息包括,根据所述设备标识通过所述第二接口将携带有该设备标识的消息发送给与所述设备标识对应的设备驱动。
3.根据权利要求1所述的方法,其特征在于,还包括对通过所述设备驱动接入的设备进行状态检测和管理。
4.根据权利要求1至3中任一项所述的方法,其特征在于,所述设备驱动为NDIS设备驱动,和/或,所述上层协议为RIL。
5.一种设备驱动消息处理装置,其特征在于包括第一传输模块,用于通过提供给上层协议的第一接口,与所述上层协议对应的上层进行消息的传输;消息处理模块,用于将来自所述上层协议的消息按照设备驱动所支持的协议进行封装,并且,将来自所述设备驱动的消息使用所述设备驱动所支持的协议将该消息解封装为所述上层协议所支持的消息格式;第二传输模块,用于通过提供给所述设备驱动的第二接口,与所述设备驱动传输消息, 其中,该消息的格式为所述设备驱动所支持的协议的格式。
6.根据权利要求5所述的装置,其特征在于,所述第二传输模块,用于在通过所述第一接口进行传输的消息中携带有设备标识的情况下,根据所述设备标识通过所述第二接口将携带有该设备标识的消息发送给与所述设备标识对应的设备驱动。
7.根据权利要求5所述的装置,其特征在于,还包括设备管理模块,用于对通过所述设备驱动接入的设备进行状态检测和管理。
8.根据权利要求5至7中任一项所述的装置,其特征在于,所述设备驱动为NDIS设备驱动,和/或,所述上层协议为RIL。
全文摘要
本发明公开了设备驱动消息处理方法及装置,该方法包括如下步骤通过提供给上层协议的第一接口,与上层协议对应的上层进行消息的传输;将来自上层协议的消息按照设备驱动所支持的协议进行封装,并且,将来自设备驱动的消息使用设备驱动所支持的协议将该消息解封装为上层协议所支持的消息格式;通过提供给设备驱动的第二接口,与设备驱动传输消息,其中,该消息的格式为设备驱动所支持的协议的格式。通过本发明提高了操作系统对设备驱动的兼容性。
文档编号G06F13/10GK102360307SQ20111023588
公开日2012年2月22日 申请日期2011年8月17日 优先权日2011年8月17日
发明者李焰峰, 范锁平 申请人:中兴通讯股份有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1