CN106528133B - 一种应用于多系统的设备请求处理方法及装置 - Google Patents

Abstract

本发明提供了一种应用于多系统的设备请求处理方法及装置，该方法步骤如下：经Linux用户空间接收来自当前系统的设备操作请求；根据操作请求，打开对应设备；判断当前系统处于前台还是后台，若当前系统处于前台，依据操作请求，控制设备执行操作；若当前系统处于后台，对操作请求进行记录或/和将操作请求对应的任务挂起。由于本发明实现于Linux内核，将处于后台的系统对应的任务保存并挂起，确保后台系统无法操控设备，同时保证后台切换到前台时，能够正常使用设备；本发明不仅实现了设备复用，而且完美实现了设备操作的流畅性和无间断性，避免了因前后台系统切换可能引起的任务出错等问题。

Description

一种应用于多系统的设备请求处理方法及装置

技术领域

本发明属于通信设备技术领域，涉及一种设备虚拟化技术，尤其涉及一种应用于多系统的设备请求处理方法及装置。

背景技术

Linux系统是一种开源电脑操作系统内核，“内核”指的是一个提供硬件抽象层、磁盘及文件系统控制、多任务等功能的系统软件。而不同的硬件设备有各自不同的控制方法和操作逻辑，如果内核针对每一套硬件都做一份特别的适配则会对内核开发难度和上层应用程序使用硬件带来极大的困难；为了适配于大量的不同的硬件平台，因此Linux内核对每一个子系统都定义了一套标准的操作框架，不同硬件平台厂商按照该框架来完成自己的设备驱动设计，并将驱动交给该框架统一管理。

为了使上层应用进程在不同硬件平台使用同类型设备时可以有统一的调用方法，在某些操作框架中，Linux自身实现了一个规范化的驱动，用于管理内核中的某一类设备；该驱动向用户层提供标准的调用接口，同时隐藏底层该设备驱动的实现细节；底层具体硬件的设备驱动通过该驱动提供的函数向其注册，并让其负责控制自身的函数调用，用户进程只需要通过规范的接口标准调用该规范化的设备驱动就能够完成对硬件的控制，例如Linux内核中的显示处理框架和音频处理框架就采用了这种方式。

音频处理架构为基于ALSA(Advanced Linux Sound Architecture，高级Linux声音架构的简称)，该架构主要分为两个部分:用户空间部分和驱动部分。用户空间部分主要是由Google定制化裁减了ALSA LIB形成了自己独有的tinyalsa，向用户空间提供接口，Tinyalsa可以分为三部分，即播放实例、录音实例和控件设置实例，Android HAL层通过调用上述实例完成播放、录音和调控设备等操作。Tinyalsa的每一个实例都有一个完整的流程，例如播放实例的流程包括打开设备、获取设备参数、设置参数、播放声音等，这个完成的流程是通过架构的驱动部分来完成的。ALSA driver处于内核，是一个完整的设备驱向用户空间提供(open、close、read、write、ioctl)来实现使用音频设备。

在多Android系统同时运行但只有一个音频设备的情况下，现有技术方案是将虚拟化实现在Framework层中，具体步骤为：APP请求使用音频服务，binder驱动截获服务请求，binder驱动作为服务端对请求进行过滤，若通过过滤规则则为其请求Audio Finger服务，否则不予响应或者返回虚假响应。

然而，随着Android的音频处理日趋多样化，现有的技术方案已不适用。首先，Android在播放声音的时候不仅会涉及到Audio Flinger还会涉及到Audio Manager,AudioPolicy等服务，各个服务之间还会交互，对于binder驱动来说过滤机制相当复杂，稍有不当的过滤策略就会影响APP使用音频服务；其次，当前后台Android系统发生切换的时候，无法保存前台设备的状态和播放进度等，当Android系统再次切换到前台时，该系统对应的设备状态是未知的，不可预测的。

发明内容

本发明的目的旨在针对上述现有技术中存在的问题，提供一种应用于多系统的设备请求处理方法及装置，实现前后台系统能够正常使用设备，确保后台系统无法操控设备，并在后台系统切换到前台时，实现任务的唤醒，恢复现场。

为了达到以上目的，本发明采用以下技术方案来实现。

本发明提供了一种应用于多系统的设备请求处理方法，其特征在于，步骤如下：

S1，经Linux用户空间接收来自当前系统的设备操作请求；

S2，根据操作请求，打开对应设备；

S3，判断当前系统处于前台还是后台，若当前系统处于前台，依据操作请求，控制设备执行操作；若当前系统处于后台，将操作请求对应的任务挂起。

上述应用于多系统的设备请求处理方法，根据操作请求，打开对应设备包括以下分步骤：

S21，根据操作请求获取当前任务结构体；

S22，根据当前任务结构体判断当前系统处于前台还是后台；

S23，若操作请求来自前台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，打开对应设备，同时将设备打开成功的消息反馈给当前系统；

S24，若操作请求来自后台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，再将打开对应设备的任务挂起。

上述应用于多系统的设备请求处理方法，步骤S3或步骤S24中，挂起具体实现方式为将任务对应的进程修改为休眠状态，并利用Linux内核调度函数将其挂起。

上述应用于多系统的设备请求处理方法，步骤S3中，通过当前任务结构体或者记录的与当前系统对应的映射关系判断当前系统处于前台还是后台。

上述应用于多系统的设备请求处理方法，进一步包括步骤S4，根据停止操作的请求关闭对应设备或者执行操作结束后关闭对应设备，该步骤包括以下分步骤：

S41，通过当前任务结构体或者记录的与当前系统对应的映射关系判断当前系统处于前台还是后台；

S42，若当前系统处于前台，则释放对应设备、清空设备状态，然后清空记录的对应设备参数信息；

S43，若当前系统处于后台，则清空记录的对应设备参数信息即可。

上述应用于多系统的设备请求处理方法，其特征在于，当处于后台的当前系统切换到前台时，包括以下步骤：

K1，将来自前台系统的操作请求挂起，释放对应设备，完成前台系统到后台系统的切换；

K2，根据记录的与当前系统对应的设备参数信息，重新打开设备，设置设备参数信息，然后唤醒记录的与当前系统对应的操作请求，加入任务序列，控制设备执行操作。

本发明进一步提供了一种应用于多系统的设备请求处理装置，其特征在于，包括：

接收子装置，用于经Linux用户空间接收来自当前系统的设备操作请求；

打开子装置，用于根据操作请求，打开对应设备，记录设备参数信息；

操作子装置，判断当前系统处于前台还是后台，若当前系统处于前台，依据操作请求，控制设备执行操作；若当前系统处于后台，将操作请求对应的任务挂起。

打开子装置进一步包括以下单元：

获取单元，用于根据操作请求获取当前任务结构体；

第一判断单元，用于根据当前任务结构体判断当前系统处于前台还是后台；

第一处理单元，若操作请求来自前台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，打开对应设备，同时将设备打开成功的消息反馈给当前系统；

第二处理单元，若操作请求来自后台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，再将打开对应设备的任务挂起。

上述述应用于多系统的设备请求处理装置，进一步包括关闭子装置，用于根据停止操作的请求或者执行操作结束后关闭对应设备的，该子装置包括以下单元：

第二判断单元，用于通过当前任务结构体或者记录的与当前系统对应的映射关系判断当前系统处于前台还是后台；

第一后处理单元，用于当前系统处于前台时释放对应设备、清空设备状态，然后清空记录的对应设备参数信息；

第二后处理单元，用于若当前系统处于后台时清空记录的对应设备参数信息即可。

上述述应用于多系统的设备请求处理装置，当处于后台的当前系统切换到前台时，进一步包括：

第一切换子装置，用于将来自前台系统的操作请求挂起，释放对应设备，完成前台系统到后台系统的切换；

第二切换子装置，用于根据记录的与当前系统对应的设备参数信息，重新打开设备，设置设备参数信息，然后唤醒记录的与当前系统对应的操作请求，加入任务序列，控制设备执行操作。

本发明提供的应用于多系统的设备复用方法及装置，具有以下至少一项有益效果：

1、由于本发明实现于Linux内核，将处于后台的系统对应的任务保存并挂起，确保后台系统无法操控设备，同时保证后台切换到前台时，能够正常使用设备；

2、由于本发明虚拟化技术实现于Linux内核，前后台系统切换效率更高，且面向设备，架构更加简洁；

3、由于本发明请求处理方法不仅实现了设备复用，而且完美实现了设备操作的流畅性和无间断性，避免了因前后台系统切换可能引起的任务出错等问题；

4、由于本发明采用的音频请求处理方法实现于Linux内核的ALSA驱动，具有跨平台强、跨版本性强等特点，便于移植。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，以下将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，以下描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图所示实施例得到其它的实施例及其附图。

图1为本发明实施例的应用于多系统的设备请求处理方法流程图。

图2为本发明实施例的打开数据处理设备流程图。

图3为本发明实施例的关闭对应设备流程图。

图4为本发明实施例的前台系统与后台系统切换时序图。

具体实施方式

以下将结合附图对本发明各实施例的技术方案进行清楚、完整的描述，显然，所描述实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施例，都属于本发明所保护的范围。

本实施例应用于多系统的设备复用方法实现于Linux内核，不再面向系统(如手机软件APP)实现虚拟化，而是在Linux内核面向设备实现虚拟化。本实施例以面向音频设备实现虚拟化为例，对应用于多系统的设备请求处理方法进行详细解释，但该解释并不构成对本发明的任何限定。

前面已经介绍过，音频设备位于音频ALSA驱动层中。Android系统音频驱动模块简记为ALSA driver，负责处理Android系统传递到内核的音频处理请求，通过读取上层传递的参数和数据设置控件状态、播放或录音等。ALSA driver模块包括Control设备和Pcm设备，其中Control设备是音频控制设备(用于管理控件，即控件管理设备)；Pcm设备用于播放或录音(用于对上层传递的数据进行解析转换，即数据处理设备)，其下可以至少有一个substream子设备负责具体的播放或录音任务(本实施例中假设一个Pcm设备下有一个substream子设备)。下面以针对Control设备和Pcm设备的操作请求为例，对本发明提供的实现与Linux内核、应用于多系统的设备请求处理方法进行详细解释。

图1示出了本实施例提供的应用于多系统的设备请求处理方法流程图，步骤如下：

S1，经Linux用户空间接收来自当前系统的设备操作请求。

用户通过上层系统(例如Android系统)发起设备操作请求，并经Linux用户空间传送至Linux内核。

在处理应用于多系统的音频操作请求时，首先经Linux用户控件接收来自当前系统的音频操作请求，以播放声音为例，用户通过上层Android系统发起播放请求，播放请求经Linux用户空间传送至Linux内核。

S2，根据操作请求，打开对应设备。

当Linux内核接收到设备操作请求以后，首先要打开对应设备，才能对设备进行操作。对于音频操作请求，即打开控件管理设备或/和数据处理设备。这是因为在ALSA驱动中，Pcm设备用于播放、Control设备用于设置控件状态，因此需要打开的至少其中一个设备。以播放声音为例，首先要打开播放设备，才能将播放声音的数据传递给播放设备，由播放设备播放声音。

上述Control设备用于管理音频控件，当Android系统要打开一个Pcm设备或者增减声音之类的操作之时，首先需要保证该设备处于打开状态，然后由Control设备管理各个音频控件的状态(如MIX控件，MUX控件，输入、输出线路等)，确保控件已达到所需要求的状态，Control设备只有在内核启动时，才涉及打开操作，内核启动后Android系统启动，打开control设备；Linux内核初始化所有控件，为每个Android系统建立一张用于记录所有控件状态的控件表，并对每个控件最后一次设置的参数进行记录(该记录由Linux内核在Android系统关闭设备或者系统切换时进行保存，以为现场恢复提供设备参数)。

根据音频操作请求，Pcm设备的打开流程如图2所示，包括以下分步骤：

S21，根据操作请求获取当前任务结构体。

根据音频操作请求进程，可以获取当前进程的当前任务结构体，当前任务结构体包含指向与当前系统对应容器的标识位。

例如，以打开Pcm设备的操作请求为例，其包括

struct task_struct*task＝current；//获取任务结构体

struct nsproxy*nsproxy＝task->nsproxy；//获取当前任务对应namespace

if(nsproxy＝＝active_nsproxy){}//判断容器是否处于前台

内核在执行打开过程时可以根据current宏(内核提供支持)，获取到对应当前请求的任务结构体指针(task_struct)，通过该指针能访问结构体中的namespace指针，这里的namespace指针即为当前系统对应容器的标识位。

S22，根据当前任务结构体判断当前系统处于前台还是后台。

通过当前结构体中包含的指向与当前系统对应容器的标识位可以确定当前系统处于前台还是后台。

例如，将获取的当前结构体中的namespace指针与前台系统对应的namespace指针进行比较则可判断当前系统处于前台还是后台。

S23，若操作请求来自前台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，打开对应设备，同时将设备打开成功的消息反馈给当前系统。

S24，若操作请求来自后台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，再将打开对应设备的任务挂起。

步骤S23和S24的目的是根据当前系统处于前台还是后台来决定是否真实打开对应设备。

以播放声音为例，当Android系统需要播放声音时，需要打开设备和设置相关参数，不管Android系统来自前台还是后台，都需要先找到当前Android系统与对应设备(这里是Pcm设备)的映射关系，然后将设备参数信息保存到相应的位置。可以通过多种记录方式(例如链表、HASH表)来保存映射关系。上述映射关系包括设备参数信息、当前进程对应的任务结构体((task_struct)：current)对应的指针、设备文件(struct file*file)结构体指针等；所述设备参数主要包括硬件参数(hw_params)、软件参数(sw_params)以及对应的命名空间(namespace)指针。若找不到当前Android系统与Pcm设备的映射关系，则需要创建两者的映射关系，并保存到链表等记录方式中，然后也将设备参数信息保存到链表中。

若当前Android系统处于前台，按照常规操作，记录完设备参数信息后，打开Pcm设备，完成打开流程，同时将Pcm设备打开成功的消息反馈给当前Android系统，这样当前Android系统才会继续传递播放声音的数据。在打开完成之后，传递声音数据之前，进一步将Android系统设置的设备相关参数作为设备参数信息保存到链表中，同时将当前设备状态保存到相应的设备状态结构体；当多个系统进行切换时，可以通过重设这些参数的方式来恢复设备，从而恢复设备的状态。

若当前Android系统处于后台，为了不影响前台Android系统使用Pcm设备，对于当前Android系统，记录完设备参数信息后，将打开Pcm设备的任务挂起，这样打开Pcm设备的任务被阻塞，直到被唤醒才能继续播放流程。

这里的挂起操作，可以采用本领域披露的操作方法，本实施例采用的实现方式是将打开Pcm设备任务对应的进程修改为休眠状态，并利用Linux内核调度函数将其挂起。

S3，判断当前系统处于前台还是后台，若当前系统处于前台，依据操作请求，控制设备执行操作；若当前系统处于后台，记录操作请求或/和将操作请求对应的任务挂起。

本步骤的目的是根据当前系统处于前台还是后台来决定是否要依据操作请求，对设备进行操作。由于在步骤S2中可能已经对前后台进行过判断，因此，本步骤中对于前后台的判断不一定是必须的。当步骤S2中未对前后台系统进行过判断时，则需要对前后台系统进行判断。

以播放声音为例，就是根据当前系统处于前台还是后台决定是否需要播放声音；前面已经指出，首先需要将各控件设置为所需状态，才能进行相应的操作，因此，Control设备和Pcm设备均会接收到播放声音的操作请求(ioctl)，下面对Control设备和Pcm设备对于该操作请求的处理过程进行详细说明。

(1)对于ioctl操作请求，对Control设备的虚拟化处理过程包括以下分步骤:

L31，根据音频操作请求，获取当前任务结构体。

前面已经对当前任务结构体进行了解释，这里不再赘述。

L32，根据获取当前任务结构体判断当前系统处于前台还是后台。

在这里，通过当前任务结构体包含的指向与当前系统对应容器的标识位，便可以确定当前系统处于前台还是后台。

L33，若当前系统处于前台，依据操作请求，控制设备执行操作；在这里具体为根据音频操作请求控制控件管理设备设置控件状态，并更新控件状态至控制表。

若当前系统处于前台，根据播放声音的操作请求，控制control设备设置输入线路、MIX控件和MUX控件等，并将更新后的控件状态保存到控件表。

L34，若当前系统处于后台，仅对记录操作请求进行记录；在这里具体为根据音频操作请求更新控件状态至控制表，但不控制控件管理设备设置控件。

若当前Android系统处于后台，为了不影响前台使用控件，Control设备不能真实设置控件状态，而为了保持与上层Android系统保存的控件状态一致，仍然需要更新对应Android系统的控件表中对应控件状态。例如，若当前Android系统处于后台，根据播放声音的操作请求，更新对应控制表中输入线路、MIX控件和MUX控件等控件状态，但不真实操作control设备设置控件(也相当于忽略此任务)。

当控件使用完毕后，再由control设备根据ioctl操作请求关闭相应控件，这也主要是为了支持DAPM(DAPM是Dynamic Audio Power Management的缩写，直译过来就是动态音频电源管理的意思，DAPM是为了使基于linux的移动设备上的音频子系统，在任何时候都工作在最小功耗状态下)机制，以减少功耗。

(2)对于ioctl操作请求，对Pcm设备的虚拟化处理过程包括以下分步骤:

L31’，根据音频操作请求，获取当前任务结构体。

前面已经对当前任务结构体进行了解释，这里不再赘述。

L32’，根据获取当前任务结构体判断当前系统处于前台还是后台。

在这里，通过当前任务结构体包含的与当前系统对应容器的标识位，便可以确定当前系统处于前台还是后台。除此之外，也可以先遍历链表找出当前系统与对应设备的映射关系，然后根据映射关系找到设备对应的系统，判断当前系统处于前台系统还是后台系统。

以播放声音为例，本步骤对应的即是通过ioctl流程来完成任务调度。当通过ioctl写入数据时，用户会传入对应要操作的设备文件指针(struct file*file)，根据该项，遍历打开设备过程中建立的设备链表找到对应的表项，读取表项中记录的namespace指针，将其与前台系统的namespace指针进行比较则可判断发起“写入数据”操作请求的Android系统处于前台还是后台。

L33’，若当前系统处于前台，依据操作请求，控制设备执行操作；在这里具体为根据音频操作请求控制数据处理设备上层传递的数据进行解析转换，执行音频操作。

以播放声音为例，若处于前台，进行正常io任务(即按操作请求控制设备执行操作)，写入播放声音数据、播放声音。

L34’，若当前系统处于后台，记录操作请求并将操作请求对应的任务挂起；在这里具体为将此次音频操作请求记录保存到链表中，并利用Linux内核调度函数将其挂起。

以播放声音为例，若当前Android系统处于后台，由于没有真正打开Pcm设备，就不能进行此次io任务，需要将此次io任务保存到链表中，然后将此次io任务挂起，这里采用的是将io任务进程修改为休眠状态，再利用Linux内核调度函数将其挂起。

当执行完一次操作，为了不影响其它系统使用操作设备，需要将完成操作的设备释放。此外，当突然接到上层系统的关闭设备请求时，也需要将设备关闭、释放。

因此，上述应用于多系统的设备请求处理方法进一步包括步骤S4，根据停止操作的请求关闭对应设备或者执行操作结束后关闭对应设备，其流程图如图3所示，包括以下步骤；

S41，通过当前任务结构体或者记录的与当前系统对应的映射关系判断当前系统处于前台还是后台。

本步骤与步骤S3中相关部分解释相似，这里不再赘述。

S42，若当前系统处于前台，则释放对应设备、清空设备状态，然后清空记录的对应设备参数信息。

S43，若当前系统处于后台，则清空记录的对应设备参数信息即可。

步骤S42和步骤S43的目的是根据当前系统处于前台还是后台来决定关闭设备的策略。

当当前系统处于前台时，按照常规操作，释放对应设备、清空设备状态，然后清空记录的对应设备参数信息。以通过调度ioctl写入数据为例，当数据写完之后，就需要先释放Pcm设备，再情况Pcm设备状态，然后清空记录的Pcm设备参数信息。

当当前系统处于后台时，由于没有真正占用过此设备，因此只需要删除链表等记录的对应的设备参数信息即可。以io任务为写入数据为例，由于io任务已经被挂起，没有调度ioctl写入数据，此时只需要删除链表等记录记录的Pcm设备参数信息。

前面已经指出，Control设备是在内核启动时打开，其也在内核关闭时关闭，其关闭流程采用本领域已经披露的常规手段实现，这里不再赘述。

以上是对应用于多系统的基本操作请求的处理过程，当前后台系统进行切换时，特别是当后台系统切换到前台时，如何实现现场的恢复，接下来进行详细说明。

当前台系统与后台系统进行切换时，主要涉及前台系统切换到后台系统和后台系统切换到前台系统，时序图如图4所示，主要包括以下步骤：

K1，将来自前台系统的操作请求挂起，释放对应设备，完成前台系统到后台系统的切换。

对于正在进行IO任务的音频设备来讲(例如Pcm设备)，当进行前后台切换时，需要先将来自前台Android系统的操作请求挂起(挂起可以采用前面描述的方法)，只有当全部IO任务都挂起后，才可以释放前台所占用的所有设备(如Control设备和Pcm设备)，否则一旦释放设备，而还有IO任务进行的话，会使Android系统崩溃。

K2，根据记录的与当前系统对应的设备参数信息，重新打开设备，设置设备参数信息，然后唤醒记录的与当前系统对应的操作请求，加入任务序列，控制设备执行操作。

释放设备以后，原处于后台的系统先找到与该系统有映射关系的设备参数信息，打开相关设备，并根据记录的设备参数信息重新对设备进行设置，使设备处于可用状态，当所有相关设备均恢复以后，调用Linux内核调度函数唤醒之前挂起的任务(例如IO任务)，则可继续执行之前的流程，从而恢复上下文。当执行完操作后，也可以释放设备，清楚记录的设备信息，以减少设备占用。

由于是按照后台系统记录的设备参数信息和IO任务进行恢复，因此当系统再次发生切换时，恢复后的处理过程与当初该系统由前台变换为后台时没有区别，可以实现完美衔接。以播放或录音为例，也即可以实现切换前的现场恢复，不会导致切换回来之后，原有的播放或录音任务因出错终止。

本实施例还提供了一种应用于多系统的设备请求处理装置，包括：

接收子装置，用于经Linux用户空间接收来自当前系统的设备操作请求；

打开子装置，用于根据操作请求，打开对应设备，记录设备参数信息；

操作子装置，判断当前系统处于前台还是后台，若当前系统处于前台，依据操作请求，控制设备执行操作；若当前系统处于后台，将操作请求对应的任务挂起。

打开子装置进一步包括以下单元：

获取单元，用于根据操作请求获取当前任务结构体；

第一判断单元，用于根据当前任务结构体判断当前系统处于前台还是后台；

第一处理单元，若操作请求来自前台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，打开对应设备，同时将设备打开成功的消息反馈给当前系统；

第二处理单元，若操作请求来自后台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，再将打开对应设备的任务挂起。

上述述应用于多系统的设备请求处理装置，进一步包括关闭子装置，用于根据停止操作的请求或者执行操作结束后关闭对应设备的，该子装置包括以下单元：

第二判断单元，用于通过当前任务结构体或者记录的与当前系统对应的映射关系判断当前系统处于前台还是后台；

第一后处理单元，用于当前系统处于前台时释放对应设备、清空设备状态，然后清空记录的对应设备参数信息；

第二后处理单元，用于若当前系统处于后台时清空记录的对应设备参数信息即可。

上述述应用于多系统的设备请求处理装置，当处于后台的当前系统切换到前台时，进一步包括：

第一切换子装置，用于将来自前台系统的操作请求挂起，释放对应设备，完成前台系统到后台系统的切换；

第二切换子装置，用于根据记录的与当前系统对应的设备参数信息，重新打开设备，设置设备参数信息，然后唤醒记录的与当前系统对应的操作请求，加入任务序列，控制设备执行操作。

本领域的普通技术人员将会意识到，这里所述的实施例是为了帮助读者理解本发明的原理，应被理解为本发明的保护范围并不局限于这样的特别陈述和实施例。本领域的普通技术人员可以根据本发明公开的这些技术启示做出各种不脱离本发明实质的其它各种具体变形和组合，这些变形和组合仍然在本发明的保护范围内。

Claims (8)

1.一种应用于多系统的设备请求处理方法，其特征在于，步骤如下：

S1，经Linux用户空间接收来自当前系统的控件管理设备或数据处理设备操作请求；

S2，根据操作请求，打开对应设备；该步骤包括以下分步骤：

S21，根据操作请求获取当前任务结构体；

S22，根据当前任务结构体判断当前系统处于前台还是后台；

S23，若操作请求来自前台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，打开对应设备，同时将设备打开成功的消息反馈给当前系统；

S24，若操作请求来自后台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，再将打开对应设备的任务挂起；

S3，若当前系统处于前台，依据操作请求，控制设备执行操作；

若当前系统处于后台，

对于控件管理设备：对操作请求进行记录，具体为根据操作请求更新控件状态至控制表；

对于数据处理设备：记录操作请求并将操作请求对应的任务挂起，具体为将此次操作请求记录保存到链表中，并利用Linux内核调度函数将其挂起。

2.根据权利要求1所述应用于多系统的设备请求处理方法，其特征在于，步骤S3或步骤S24中，挂起具体实现方式为将任务对应的进程修改为休眠状态，并利用Linux内核调度函数将其挂起。

3.根据权利要求1所述应用于多系统的设备请求处理方法，其特征在于，步骤S3中，通过当前任务结构体或者记录的与当前系统对应的映射关系判断当前系统处于前台还是后台。

4.根据权利要求1所述应用于多系统的设备请求处理方法，其特征在于，进一步包括步骤S4，根据停止操作的请求关闭对应设备或者执行操作结束后关闭对应设备，该步骤包括以下分步骤：

S41，通过当前任务结构体或者记录的与当前系统对应的映射关系判断当前系统处于前台还是后台；

S42，若当前系统处于前台，则释放对应设备、清空设备状态，然后清空记录的对应设备参数信息；

S43，若当前系统处于后台，则清空记录的对应设备参数信息即可。

5.根据权利要求1、2、3或4所述应用于多系统的设备请求处理方法，其特征在于，当处于后台的当前系统切换到前台时，包括以下步骤：

K1，将来自前台系统的操作请求挂起，释放对应设备，完成前台系统到后台系统的切换；

K2，根据记录的与当前系统对应的设备参数信息，重新打开设备，设置设备参数信息，然后唤醒记录的与当前系统对应的操作请求，加入任务序列，控制设备执行操作。

6.一种应用于多系统的设备请求处理装置，其特征在于，包括：

接收子装置，用于经Linux用户空间接收来自当前系统的控件管理设备或数据处理设备操作请求；

打开子装置，用于根据操作请求，打开对应设备，记录设备参数信息；该子装置包括以下单元：

获取单元，用于根据操作请求获取当前任务结构体；

第一判断单元，用于根据当前任务结构体判断当前系统处于前台还是后台；

第一处理单元，若操作请求来自前台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，打开对应设备，同时将设备打开成功的消息反馈给当前系统；

第二处理单元，若操作请求来自后台，搜索当前系统与对应设备的映射关系，若搜索不到则创建并记录当前系统与对应设备的映射关系，然后记录设备参数信息，再将打开对应设备的任务挂起；

操作子装置，判断当前系统处于前台还是后台，若当前系统处于前台，依据操作请求，控制设备执行操作；

若当前系统处于后台，

对于控件管理设备：对操作请求进行记录，具体为根据操作请求更新控件状态至控制表；

对于数据处理设备：记录操作请求并将操作请求对应的任务挂起，具体为将此次操作请求记录保存到链表中，并利用Linux内核调度函数将其挂起。

7.根据权利要求6所述应用于多系统的设备请求处理装置，其特征在于，进一步包括关闭子装置，用于根据停止操作的请求或者执行操作结束后关闭对应设备，该子装置包括以下单元：

第二判断单元，用于通过当前任务结构体或者记录的与当前系统对应的映射关系判断当前系统处于前台还是后台；

第一后处理单元，用于当前系统处于前台时释放对应设备、清空设备状态，然后清空记录的对应设备参数信息；

第二后处理单元，用于若当前系统处于后台时清空记录的对应设备参数信息即可。

8.根据权利要求6或7所述应用于多系统的设备请求处理装置，其特征在于，当处于后台的当前系统切换到前台时，进一步包括：

第一切换子装置，用于将来自前台系统的操作请求挂起，释放对应设备，完成前台系统到后台系统的切换；

第二切换子装置，用于根据记录的与当前系统对应的设备参数信息，重新打开设备，设置设备参数信息，然后唤醒记录的与当前系统对应的操作请求，加入任务序列，控制设备执行操作。

Images