设备文件的透传方法、设备及计算机存储介质

技术领域

本发明涉及容器技术，尤其涉及一种设备文件的透传方法、设备及计算机存储介质。

背景技术

在物理服务器上直接运行容器中的安卓系统的技术具有启动速度快的特点，同时启动的容器可以直接访问物理服务器上的设备。但是一个物理服务器上的所有容器共享宿主机内核，存在严重的安全隐患。Kata container项目的主要目标是通过一个轻量的虚拟机来构建安全容器。构建基于Kata container的虚拟化环境可以将虚拟机的安全隔离优势和容器的快速启动特点结合起来。

但是，构建基于Kata container的虚拟化环境存在两个问题。一方面，基于Katacontainer的容器运行环境是虚拟机运行Kata agent创建的，并不是运行虚拟机的宿主机创建的，当在运行虚拟机的宿主机上启动Kata container容器中的安卓系统时是不能把物理服务器上的设备透传给Kata container容器的，所以如何把虚拟机上的设备透传给容器这是一个关键技术难题。而且容器中的安卓系统需要的设备还依赖于其他文件，这些文件都是容器中的安卓系统正常运行所需要的，但是这些文件是虚拟机运行时加载驱动动态生成的无法在制作容器镜像的时候生成。

另一方面，Kata container依赖的内核和根文件系统都是非常精简的，所以缺乏运行容器中的安卓系统所需要的驱动，比如/dev/binder等，而且Kata虚拟机无法动态加载这些驱动模块。

发明内容

有鉴于此，本申请实施例提供一种设备透传方法、设备及计算机存储介质，解决Kata container访问所属虚拟机中设备文件失败的问题。

本申请实施例提供了一种设备文件的透传方法，所述方法包括：

以第一预设模式创建虚拟机镜像；

基于所述虚拟机镜像，以第二预设模式启动虚拟机；

以第三预设模式在所述虚拟机中创建容器；

基于预设路径，在所述容器中创建设备依赖文件；

按照所述预设路径，使所述虚拟机中的容器对所述设备依赖文件进行成功访问；

基于所述虚拟机的透传策略以及访问到的所述设备依赖文件，使所述虚拟机中的容器对待访问设备文件进行成功访问。

在一实施例中，所述以第一预设模式创建虚拟机镜像，包括：

新增非根用户对所述虚拟机中所述待访问设备文件的预设权限；

将所述虚拟机中新增的驱动编译为内核内置模式。

在一实施例中，所述基于所述虚拟机镜像，以第二预设模式启动虚拟机，包括：

新增所述虚拟机中所述待访问设备文件对应的设备参数。

在一实施例中，所述以第三预设模式在虚拟机中创建容器，包括：

基于所述待访问设备文件注册时采用的配置数据，获取所述虚拟机的设备数据以创建所述容器。

在一实施例中，所述基于所述虚拟机的透传策略以及访问到的所述设备依赖文件，使所述虚拟机中的容器对待访问设备文件进行成功访问，包括：

基于所述虚拟机中容器的硬件配置信息，创建所述容器的子系统；

将所述待访问设备文件添加至所述子系统的可访问列表中；

创建子进程；

使所述子进程利用所述容器的子系统对所述虚拟机中的待访问设备文件进行访问。

在一实施例中，所述基于预设路径，在所述容器中创建设备依赖文件，包括：

获取所述容器的根文件系统在所述虚拟机中的第一路径；

获取虚拟机中的所述设备依赖文件的第二路径；

结合所述第一路径与所述第二路径，在所述容器中构建所述设备依赖文件的存放目录，生成所述预设路径；

基于所述虚拟机中待访问设备文件对应的设备属性，在所述预设路径中的存放目录里创建设备依赖文件。

在一实施例中，所述非根用户的预设权限至少包括可读权限、可写权限以及可执行权限。

在一实施例中，所述配置数据至少包括主设备号以及次设备号。

为实现上述目的，还提供一种计算机存储介质，所述计算机存储介质上存储有设备文件的透传方法程序，所述设备文件的透传方法程序被处理器执行时实现上述任一所述的设备文件的透传方法的步骤。

为实现上述目的，还提供一种设备文件的透传设备，包括存储器，处理器及存储在所述存储器上并可在所述处理器上运行的设备文件的透传方法程序，所述处理器执行所述设备文件的透传方法程序时实现上述任一所述设备文件的透传方法方法的步骤。

本申请实施例中提供的一个或多个技术方案，至少具有如下技术效果或优点：

以第一预设模式创建虚拟机镜像；通过第一预设模式创建虚拟机镜像，可以将虚拟机中新增的驱动编译为内核内置模式，以及增加非根用户权限以保证以第一预设模式创建的虚拟机镜像能够提供容器访问待访问设备文件的数据。

基于所述虚拟机镜像，以第二预设模式启动虚拟机；通过将待访问设备文件所需要的设备参数等进行增加来启动虚拟机，保证虚拟机能够保证待访问设备文件能够顺利访问。

以第三预设模式在所述虚拟机中创建容器；通过第三预设模式在虚拟机中创建容器时，可以另外获取虚拟机的设备数据以保证虚拟机中创建的容器能够访问虚拟机中的待访问设备文件。

基于预设路径，在所述容器中创建设备依赖文件；通过预设路径，基于虚拟机中的设备依赖文件，在虚拟机中的容器里进行创建，以保证容器对虚拟机中的待访问设备文件进行顺利且成功的访问。

按照所述预设路径，使所述虚拟机中的容器对所述设备依赖文件进行成功访问；通过预设路径，保证了虚拟机中的容器对待访问设备文件成功访问。

基于所述虚拟机的透传策略以及访问到的所述设备依赖文件，使所述虚拟机中的容器对待访问设备文件进行成功访问；通过虚拟机的透传策略将虚拟机中的待访问设备文件透传至虚拟机中的容器中，结合访问到的设备依赖文件，则可以成功且顺利的对待访问设备文件进行访问。

本申请实施例解决了Kata container访问所属虚拟机中设备文件失败的问题，实现了Kata container成功访问所属虚拟机的设备文件并执行操作。

附图说明

图1为本申请设备文件透传方法的第一实施例的流程示意图；

图2为本申请设备文件透传方法的第一实施例中步骤S110的具体流程示意图；

图3为本申请设备文件透传方法的第一实施例中步骤S120的具体流程示意图；

图4为本申请设备文件透传方法的流程示意图；

图5为本申请设备文件透传方法的第一实施例中步骤S130的另一具体流程示意图；

图6为本申请设备文件透传方法的第一实施例中步骤S160的具体流程示意图；

图7为本申请设备文件透传方法的第一实施例中步骤S140的具体流程示意图；

图8为Kata虚拟机中运行操作系统为Android的容器的示例图；

图9为本申请设备文件透传方法的实施前后的结果对比图；

图10为本申请实施例中涉及的设备文件透传方法的硬件架构示意图。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例的主要解决方案是：以第一预设模式创建虚拟机镜像；基于所述虚拟机镜像，以第二预设模式启动虚拟机；以第三预设模式在所述虚拟机中创建容器；基于预设路径，在所述容器中创建设备依赖文件；按照所述预设路径，使所述虚拟机中的容器对所述设备依赖文件进行成功访问；基于所述虚拟机的透传策略以及访问到的所述设备依赖文件，使所述虚拟机中的容器对待访问设备文件进行成功访问；本发明解决了Katacontainer访问所属虚拟机中设备文件失败的问题，实现了Kata container成功访问所属虚拟机的设备文件并执行操作。

为了更好的理解上述技术方案，下面将结合说明书附图以及具体的实施方式对上述技术方案进行详细的说明。

参照图1，图1为本申请设备文件的透传方法的第一实施例，所述方法包括：

步骤S110：以第一预设模式创建虚拟机镜像。

具体地，镜像（Mirroring）是一种文件存储形式，是冗余的一种类型，一个磁盘上的数据在另一个磁盘上存在一个完全相同的副本即为镜像。

虚拟机镜像可以是一种虚拟机镜像文件，是一个安装有操作系统的磁盘分区，保存了虚拟机硬盘的全部信息。

步骤S120：基于所述虚拟机镜像，以第二预设模式启动虚拟机。

具体地，虚拟机（Virtual Machine）是指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。在实体计算机（物理机或宿主机）中能够完成的工作在虚拟机中都能够实现。在计算机中创建虚拟机时，需要将实体机的部分硬盘和内存容量作为虚拟机的硬盘和内存容量。每个虚拟机都有独立的CMOS（ComplementaryMetal-Oxide-Semiconductor，互补金属氧化物半导体）传感器、硬盘和操作系统，可以像使用实体机一样对虚拟机进行操作。虚拟机可以是虚拟化环境，并不限定于虚拟机。

步骤S130：以第三预设模式在所述虚拟机中创建容器。

具体地，容器技术可以有效的将单个操作系统的资源划分到孤立的组中，以便更好的在孤立的组之间平衡有冲突的资源使用需求，所述孤立的组称为一个个相互隔离的容器。容器技术可以同时将操作系统镜像和应用程序加载到内存当中。还可以从网络磁盘进行加载，因此同时启动几十台镜像不会对网络和存储带来很大负载。之后的镜像创建过程只需要指向通用镜像，大大减少了所需内存。

需要另外说明的是，所述容器具体可以是Kata container，在此并不限定于Katacontainer，也可以是其他运行时依赖比较精简的内核以及根系统文件的容器。

Kata container弥补了传统容器技术安全性的缺点，通过使用硬件虚拟化来达到容器隔离的目的。每一个容器（container/pod）都是基于一个独立的操作系统内核实例来作为一个轻量级的虚拟机。

步骤S140：基于预设路径，在所述容器中创建设备依赖文件。

具体地，所述设备依赖文件可以是容器中的操作系统访问虚拟机中的待访问设备文件所需的文件，若这些设备依赖文件不能成功访问，则会导致待访问设备文件也不能成功访问。

具体地，所述预设路径可以是解决对虚拟机中的设备依赖文件的访问问题。

步骤S150：按照所述预设路径，使所述虚拟机中的容器对所述设备依赖文件进行成功访问。

具体地，根据预设路径的顺序，可以使得虚拟机中的容器对设备依赖文件进行成功访问。

步骤S160：基于所述虚拟机的透传策略以及访问到的所述设备依赖文件，使所述虚拟机中的容器对待访问设备文件进行成功访问。

具体地，将虚拟机中的待访问设备文件经过虚拟机的透传策略传递至虚拟机中的容器中，结合访问到的设备文件正常访问时所需的设备依赖文件，则可以使虚拟机中的容器对待访问设备文件进行成功访问。

上述实施例中，存在的有益效果为：

以第一预设模式创建虚拟机镜像；通过第一预设模式创建虚拟机镜像，可以将虚拟机中新增的驱动编译为内核内置模式，以及增加非根用户权限以保证以第一预设模式创建的虚拟机镜像能够提供容器访问待访问设备文件的数据。

基于所述虚拟机镜像，以第二预设模式启动虚拟机；通过将待访问设备文件所需要的设备参数等进行增加来启动虚拟机，保证虚拟机能够保证待访问设备文件能够顺利访问。

以第三预设模式在所述虚拟机中创建容器；通过第三预设模式在虚拟机中创建容器时，可以另外获取虚拟机的设备数据以保证虚拟机中创建的容器能够访问虚拟机中的待访问设备文件。

基于预设路径，在所述容器中创建设备依赖文件；通过预设路径，基于虚拟机中的设备依赖文件，在虚拟机中的容器里进行创建，以保证容器对虚拟机中的待访问设备文件进行顺利且成功的访问。

按照所述预设路径，使所述虚拟机中的容器对所述设备依赖文件进行成功访问；通过预设路径，保证了虚拟机中的容器对待访问设备文件成功访问。

基于所述虚拟机的透传策略以及访问到的所述设备依赖文件，使所述虚拟机中的容器对待访问设备文件进行成功访问；通过虚拟机的透传策略将虚拟机中的待访问设备文件透传至虚拟机中的容器中，结合访问到的设备依赖文件，则可以成功且顺利的对待访问设备文件进行访问。

本申请实施例解决了Kata container访问所属虚拟机中设备文件失败的问题，实现了Kata container成功访问所属虚拟机的设备文件并执行操作。

参照图2，图2为本申请设备文件的透传方法第一实施例中步骤S110的具体实施步骤，所述以第一预设模式创建虚拟机镜像，包括：

步骤S111：新增非根用户对所述虚拟机中所述待访问设备文件的预设权限。

具体地，增加非根用户对虚拟机中所述待访问设备文件的预设权限，使得虚拟机上启动的程序以及虚拟机中容器的Kata agent能够有权限访问设备。

需要另外说明的是，新增非根用户的预设权限可以通过更改原始的linux内核驱动代码来完成。

其中，Kata agent为Kata container的一个重要组件，管理容器和处理容器的运行，另外，Kata container还包括Kata runtime、Kata proxy、Kata shim、Katahypervisor，其中，Kata runtime是一个OCI（Open Container Initiative）兼容运行时，负责OCI运行时规范指定的所有命令并启动Kata shim。

步骤S112：将所述虚拟机中新增的驱动编译为内核内置模式。

具体地，可以是将虚拟机中新增的内核驱动编译成为内核内置模块的模式，以克服虚拟机中的容器不能动态加载内核模块的问题。

上述实施例中，存在的有益效果为：制作了一个带有所需设备驱动的虚拟机镜像，使得虚拟机中的容器可以动态加载内核模块，从而可以动态加载容器中的操作系统所需要的驱动，保证容器中的操作系统能够正常运行。

参照图3，图3为本申请设备文件的透传方法第一实施例中步骤S120的具体实施步骤，所述基于所述虚拟机镜像，以第二预设模式启动虚拟机，包括：

步骤S121：新增所述虚拟机中所述待访问设备文件对应的设备参数。

具体地，在本实施例中如图4所示的Kata runtime在利用模拟处理器创建虚拟机时，新增待访问设备文件对应的设备参数，比如-device usb -ehci，从而确保虚拟机中容器里的操作系统需要的设备能够正常创建，其中，所述虚拟机中容器里的操作系统可以是Android系统，也可以是IOS系统，也可以是Windows系统，在此并不限定，其中模拟处理器可以是QEMU（虚拟操作系统模拟器），子系统可以是cgroup decive。

上述实施例中，存在的有益效果为：通过将待访问设备文件所需要的设备参数等进行增加来启动虚拟机，保证虚拟机能够保证待访问设备文件能够顺利访问。

参照图5，图5为本申请设备文件的透传方法第一实施例中步骤S130的具体实施步骤，所述以第三预设模式在虚拟机中创建容器，包括：

步骤S131：基于所述待访问设备文件注册时采用的配置数据，获取所述虚拟机的设备数据以创建容器。

具体地，利用Kata agent创建容器时，Kata agent根据待访问设备文件注册时采用的主设备号与次设备号，获取虚拟机上的设备与设备类型等信息。其中，如图4所示，配置数据可以是主设备号与次设备号，也可以是其他的数据；同理设备数据可以是设备与设备类型，设备地址、设备大小等信息，也可以是其他的数据，在此并不作限定。

上述实施例中，存在的有益效果为：获取虚拟机上的设备数据以创建容器，为容器能够正常访问设备文件提供数据支持，保证容器能够正常访问设备文件。

参照图6，图6为本申请设备文件的透传方法第一实施例中步骤S160的具体实施步骤，所述基于所述虚拟机的透传策略以及访问到的所述设备依赖文件，使所述虚拟机中的容器对待访问设备文件进行成功访问，包括：

步骤S161：基于所述虚拟机中容器的硬件配置信息，创建所述容器的子系统。

具体地，所述硬件配置信息可以是CPU的分配情况以及内存的分配情况等，如图4所示，kata agent利用硬件配置信息的具体设置创建容器的子系统。其中，cgroup子系统可以包含多个，且cgroup子系统由虚拟机管理，虚拟机控制cgroup子系统，从而使cgroup子系统可以控制容器访问的资源的大小及权限等，在本实施例中，所述子系统可以是cgroupdevice，但不限定于cgroup device子系统。

需要另外说明的是，cgroup子系统包括以下：

blkio为块设备设定输入/输出限制，比如物理设备（磁盘，固态硬盘，USB 等）；

cpu 使用调度程序提供对CPU的cgroup任务访问；

cpuacct自动生成cgroup中任务所使用的CPU报告；

cpuset为cgroup中的任务分配独立CPU（在多核系统）和内存节点；

devices 可允许或者拒绝cgroup中的任务访问设备；

freezer挂起或者恢复cgroup中的任务；

memory 设定cgroup中任务使用的内存限制，并自动生成由那些任务使用的内存资源报告；

net_cls使用等级识别符（classid）标记网络数据包，可允许Linux流量控制程序（tc）识别从具体cgroup中生成的数据包；

ns为名称空间子系统。

步骤S162：将所述待访问设备文件添加至所述子系统的可访问列表中；

步骤S163：创建子进程；

具体地，所述子进程可以由runc init创建。

步骤S164：使所述子进程利用所述容器的子系统对所述虚拟机中的待访问设备文件进行访问。

具体地，子进程可以利用容器中对应的cgroup device对所述待访问设备文件进行访问。

在上述实施例中，依据配置信息创建容器，并将待访问设备文件添加至可访问列表，保证了容器能够成功访问待访问设备文件。

参照图7，图7为本申请设备文件的透传方法第一实施例中步骤S140的具体实施步骤，所述基于预设路径，在所述容器中创建设备依赖文件，包括：

步骤S141：获取所述容器的根文件系统在所述虚拟机中的第一路径；

具体地，根文件系统（rootfs）首先是一种文件系统，该文件系统不仅具有普通文件系统的存储数据文件的功能，而且相对于普通的文件系统，它的特殊之处在于，它是内核启动时所挂载（mount）的第一个文件系统，内核代码的映像文件保存在根文件系统中，系统引导启动程序会在根文件系统挂载之后从中把一些初始化脚本（如rcS,inittab）和服务加载到内存中去运行。

具体地，所述第一路径可以为存储路径，可以是相对路径，也可以是绝对路径，在此并不限定。

步骤S142：获取虚拟机中的所述设备依赖文件的第二路径；

具体地，所述第二路径可以为存储路径，可以是相对路径，也可以是绝对路径，在此并不限定。

步骤S143：结合所述第一路径与所述第二路径，在所述容器中构建所述设备依赖文件的存放目录，生成所述预设路径；

具体地，所述预设路径可以是相对路径，也可以是绝对路径。

步骤S144：基于所述虚拟机中待访问设备文件对应的设备属性，在所述预设路径中的存放目录里创建设备依赖文件；

具体地，所述待访问设备文件对应的设备属性可以是由kata agent程序进行读取。

需要说明的是，采用生成的设备依赖文件在chroot或pivot_root切换进程的根文件系统目录之后也能被容器访问。

上述实施例中，存在的有益效果为：具体给出了创建预设路径的方法，保证预设路径创建的正确性，从而保证设备依赖文件能够被成功访问。

在其中一个实施例中，所述非根用户的预设权限至少包括可读权限、可写权限以及可执行权限。

具体地，所述可读权限为可以查看文件里面的内容；所述可写权限为可以对文件的内容进行编辑；可执行操作只对脚本和目录生效，对一般的文件没有意义；所述可执行权限为可以对脚本和目录进行执行操作。

在其中一个实施例中，所述配置数据至少包括主设备号以及次设备号。

具体地，所述配置数据至少包括主设备号以及次设备，以及一些相关的配置文件，在此并不限定于主设备号以及次设备号。

需要另外说明的是，如图8所示，在kata虚拟机中运行操作系统为Android的容器的示例图，其中宿主操作系统可以为HOST OS，开源虚拟机可以为KVM，可移植容器的编排管理工具可以为K8S，模拟处理器可以为QEMU；且图9中的(a)图为改进前的kata container；图9中的(b)图为改进后的kata container；经过对比发现，采用改进的kata container，容器可以访问虚拟机的设备/dev/binder、/dev/ashmem以及/dev/input/mice。

本申请还提供一种计算机存储介质，所述计算机存储介质上存储有设备文件的透传方法程序，所述设备文件的透传方法程序被处理器执行时实现上述任一所述的设备文件的透传方法步骤。

本申请还提供一种设备文件的透传设备，包括存储器，处理器及存储在所述存储器上并可在所述处理器上运行的设备文件的透传方法程序，所述处理器执行所述设备文件的透传方法程序时实现上述任一所述设备文件的透传方法步骤。

本申请涉及一种设备文件的透传设备010包括如图10所示：至少一个处理器012、存储器011。

处理器012可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器012中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器012可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC）、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器011，处理器012读取存储器011中的信息，结合其硬件完成上述方法的步骤。

可以理解，本发明实施例中的存储器011可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ReadOnly Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的 RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double DataRateSDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器 (Synch link DRAM，SLDRAM) 和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本发明实施例描述的系统和方法的存储器011旨在包括但不限于这些和任意其它适合类型的存储器。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

应当注意的是，在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的部件或步骤。位于部件之前的单词“一”或“一个”不排除存在多个这样的部件。本发明可以借助于包括有若干不同部件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发

明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。