CN108701058B - 虚拟化传感器 - Google Patents

Abstract

公开了与虚拟化传感器相关的技术。在所公开的技术的一个示例中，一种方法可被用来分配计算系统的资源。该方法可包括枚举能够彼此交互的硬件传感器和软件模块。可协商与所枚举的硬件传感器和软件模块的能力相兼容的拓扑结构。可从第一请求者接收配置所枚举的硬件传感器和软件模块中的至少一者的第一请求。所枚举的硬件传感器和软件模块中的该至少一者可响应于接收到的第一请求来被配置。

Description

虚拟化传感器

背景

计算机的操作系统(OS)通常不允许在多个应用之间同时共享单个硬件设备。例如，第一应用可被选择成使用由给定硬件设备(诸如，计算机的相机)产生的数据(诸如，帧数据)。一旦第一应用开始使用该相机，没有其他应用能够与该第一应用同时使用该相机。然而，如果硬件资源可以在计算机上运行的多个软件应用之间共享，则计算机可具有降低的组件数和/或增加的功能性。

概述

公开了与虚拟化传感器相关的技术。在所公开的技术的一个示例中，一种方法可被用来分配计算系统的资源。该方法可包括枚举能够彼此交互的硬件传感器和软件模块。可协商与所枚举的硬件传感器和软件模块的能力相兼容的拓扑结构。可从第一请求者接收配置所枚举的硬件传感器和软件模块中的至少一者的第一请求。所枚举的硬件传感器和软件模块中的该至少一者可响应于接收到的第一请求来被配置。

附图简述

图1解说了共享虚拟化传感器群的多个应用的示例。

图2解说了示例虚拟化传感器群的各方面。

图3是包括多个传感器和分布式存储器的示例计算机系统的系统图。

图4是用于使用虚拟化传感器群的示例软件体系结构的系统图。

图5-7解说了使用虚拟化传感器群的示例方法。

图8是解说了用于实现所公开的技术的一些实施例的合适计算环境的框图。

详细描述

概览

如上所述，计算系统的OS通常不允许在多个应用之间同时共享单个硬件设备或传感器。另外，一些应用可能在该应用的执行期间使用多个硬件传感器和紧耦合的软件模块。随着应用日益复杂从而使用更多硬件资源，对于各应用而言，共享硬件资源以及具有对存在于计算系统上的资源的统一视图可以是合乎需要的。

如本文描述的，通过虚拟化各硬件和软件基础“传感器”(其产生数据流)，传感器群可潜在地呈现兼容传感器和软件模块的统一视图。具体而言，传感器群可统一各种不同类型的传感器以描述可用流、它们的媒体类型、它们的控制、以及并发地工作的那些传感器的任何限制/约束。例如，计算设备可包括使用和/或合成与传感器设备类似的流传输信息的多个传感器设备和软件应用。传感器群可将各个体硬件设备和软件模块的能力虚拟化成可由一个或多个软件应用访问的单个对象。传感器群可以确定硬件和软件的哪些组合可被一起使用且可将兼容组合的拓扑结构呈现给各应用。因而，传感器群可以提供用于以单点(ala carte)方式在多个软件应用之间共享多个硬件设备的框架。

作为解说，图1中的示例系统100可包括可被映射到N个应用(诸如应用150和160)的M个“传感器”(诸如相机120和130和流源140)。传感器120、130和140可被虚拟化并封装在传感器群110中。传感器120、130和140通常可产生流传输数据，并可包括硬件传感器、软件模块或其组合。不同应用150和160可以使用一致的API启动来自传感器群110的给定传感器，并可挑选和选择使用传感器群110内的哪些物理设备和/或软件模块。例如，应用150可以使用传感器120和130，而应用160可以使用传感器130。因而，应用150和160可以共享传感器130。传感器群110可被用来管理传感器130的共享，以使得应用150和160按兼容的方式来使用传感器130并且使得应用150和160可以与传感器群110通信而非彼此通信。通过使用传感器群110作为通信点，各应用可被屏蔽而免于知悉共享传感器群110的其他应用的要求。换言之，找出物理传感器的兼容配置可被委托给传感器群110。

传感器数据的单生产者/多消费者模型的另一潜在挑战可以是该数据从传感器生产者到应用消费者的高效传输。具体而言，降低创建要在生产者进程(例如，传感器)和各消费者进程(例如，应用)之间编排的数据的副本的开销可以是合乎需要的。作为一个示例，数据可以通过将该数据从与生产者进程相关联的物理存储器复制到与消费者进程相关联的物理存储器来从生产者进程传送到消费者进程。然而，具有数据的多个副本可在作出副本时导致对存储器资源的低效使用和对计算资源的低效使用。例如，制作并维护数据的多个副本可降低性能(因为计算周期被专用于复制数据)，降低存储器效率(因为相同数据的多个副本可阻止其他应用使用存储器资源)，并降低电池寿命(因为能量被用于存储器资源的复制和刷新)。

“共享存储器”是一种可被用来跨进程边界来发送数据的解决方案。共享存储器可以降低制作数据的多个副本的开销，但一旦数据已被发送给消费者进程，生产者就可能失去对数据的访问控制。例如，OS可分配可由生产者和消费者进程访问的共享存储器对象。具体而言，生产者进程和消费者进程可就通过使用带外通信(诸如RPC调用)来使用共享存储器对象达成一致。共享存储器对象可通过使用OS的系统API来创建。具体而言，生产者进程可以创建共享存储器对象并将它映射到其地址空间。消费者进程可以重复该过程，以便相同的物理地址范围具有到两个不同相应进程的虚拟地址空间的两个不同映射。因而，物理地址范围在不同进程之间共享。

尽管使用共享存储器对象实现了允许两个进程共享同一物理存储器的目标，但生产者失去对数据的访问控制。这是因为共享存储器对象的所有权不再被限于生产者进程。相反，因为这两个进程使用系统API来创建共享存储器对象，它由这两个进程联合拥有(在多个消费者的情形中，每一消费者进程将共享该共享存储器对象的所有权)。只要消费者进程坚持该映射，则共享存储器对象就不能被移除且存储器不能被解除分配。换言之，生产者进程没有办法来撤回从消费者进程对共享存储器对象的访问。这可造成潜在安全性和隐私弱点，因为即使生产者希望撤回读特权，消费者进程也可继续读取存储器。

如本文公开的，内核存储器反射可潜在地降低或消除复制并使生产者进程能维持访问控制。例如，代替生产者/消费者进程将存储器映射到它们的进程空间，内核组件(本文称为反射器)可以处置存储器的映射和寿命。这可通过生产者进程向反射器提供因该生产者进程而异的虚拟地址列表连同它们的大小和可消费该数据的消费者进程的列表来实现。因为生产者提供数据的经允许消费者的列表，所以反射器可以使用生产者提供的列表来确保任何非批准消费者不被允许访问经反射帧。

示例传感器群体系结构

图2解说了示例传感器群200的各方面。传感器群200可以是标识硬件传感器和可以一起使用或分开使用的相关联的软件模块的软件对象或数据结构。具体而言，传感器群200可统一各种不同类型的硬件传感器和/或软件模块以描述可用流、它们的媒体类型、它们的控制、以及并发地工作的那些传感器的任何限制/约束。传感器群200可以呈现或发布硬件传感器和/或软件模块的哪些组合可被一起使用，并可以向各应用呈现兼容的组合的拓扑结构。传感器群200可包括硬件传感器、软件传感器、以及处理引擎。

硬件传感器(诸如传感器210和220)可包括向计算机系统提供与该计算机系统和/或其环境有关的信息的硬件。例如，硬件传感器可包括用来检测光或图像(诸如可见、红外和/或紫外相机)、温度、力(诸如触觉传感器)、化学品、湿度、位置(诸如通过使用全球定位系统(GPS)信号或无线电三角测量)、取向(诸如陀螺仪)、加速度、以及其他各种环境质量的传感器。传感器可连接到或封闭在计算机系统的机架内，或者传感器可经由扩展端口或电缆连接器(诸如例如通用串行总线(USB))来连接。硬件传感器可以产生诸如表示被测量的质量的流传输输出(本文称为源流)之类的输出。硬件传感器可包括能改变硬件传感器的模式和/或影响测量的各种质量的诸控制。作为一个示例，硬件传感器可以支持在给定时间点互斥的多个不同模式或传输速率，并且各控制可被用来设置硬件传感器的模式。作为另一示例，控制可被用来改变影响流传输输出(诸如相机上的焦点控制)的设置。硬件传感器可以使用软件(诸如设备驱动程序)与计算机系统的操作系统进行通信。

作为特定示例，硬件传感器可以是安装在计算系统的机架上的相机。相机可以产生视频数据流，诸如表示世界的可见光谱视图的红绿蓝(RGB)数据。相机可被配置成使得视频数据可由相机产生、使用操作系统来捕获、并递送给可消费该相机数据的应用。相机可具有能被调整来开始、停止或改变视频输出的控制。例如，视频输出可通过改变传输速率、媒体类型、焦点、曝光、不平衡等而被改变。

处理引擎(诸如处理引擎240、250和260)是接受输入、处理该输入并生成输出(诸如经合成流)的软件模块。处理引擎可以执行各种不同功能，诸如压缩、旋转、深度分析、转码、运动跟踪、图像识别或其他功能。处理引擎可以接受来自硬件传感器和/或来自其他处理引擎的输入。作为具体示例，处理引擎240和250可各自接受来自硬件传感器210和220的输入，而处理引擎260可接受来自硬件传感器220和处理引擎240的输入。处理引擎可具有各种要求以便正确地起作用。例如，处理引擎可指定具有最小传输速率、最大传输速率、一个或一组兼容媒体类型等的一个或多个相关流。如果处理引擎的输入要求未被满足，则该处理引擎不能被使用。

作为特定示例，硬件传感器210和220可以是能够产生720p、1080p、1080i或4K视频格式的相机。处理引擎240可能够生成深度流242，但仅在来自装载在同一机架上的一对相机(例如，硬件传感器210和220)的输入212和222各自使用720p视频格式生成视频时。相机可以提供环境的立体视图。处理引擎240可以合成来自相机的两个RGB流212和222，并产生提供该视图的深度图的单个深度流242。在这一示例中，以此方式创建的深度流242是经合成流，且处理引擎240所消费的两个RGB源流212和222是相关流。只要相关流是以720p操作的，处理引擎240就可以生成深度图。然而，如果另一应用将硬件传感器210和220中的一者或两者配置成1080p，则处理引擎240不能与以1080p来使用传感器的该另一应用并发地使用。

各控制可被用来设置硬件传感器或处理引擎的模式和/或影响硬件处理器或处理引擎的操作。例如，各控制可被用来初始化传感器或引擎，开启或停止数据流，改变影响该数据的参数，等等。作为视频控制的示例，各控制可被调整以开始视频流、结束视频流、改变视频输出(诸如传输速率、媒体类型、焦点、曝光、白平衡，等等)。各控制可被级联以使得发送到处理引擎的控制动作可被馈送到生成处理引擎的相关流的传感器。作为特定示例，到处理引擎260的控制输入264可经由控制244通过处理引擎240经由控制214馈送到硬件传感器210。以此方式，应用可只与处理引擎(例如，处理引擎260)对接，而不必还与硬件引擎(例如，硬件传感器210)直接对接。

处理引擎的依存关系可以在处理引擎的依存关系数据结构(例如，依存关系246、256、266)中维护。例如，依存关系数据结构可被用来列出或跟踪相关流、相关流的任何要求、上游传感器或处理引擎的控制接口、以及处理引擎的任何其他要求。作为特定实例，处理引擎240(例如，深度流组件)的依存关系246可包括相关流(例如，来自左RGB相机的流，诸如流212，以及来自右RGB相机的流，诸如流222)、该流所需的传输速率和/或媒体类型(例如，720p)、以及到硬件传感器的控制接口(例如，控制214)。如下文进一步描述的，依存关系数据结构可以在生成传感器群的拓扑结构时使用。

传感器群200可以呈现或发布在给定时刻合法或兼容的一个或多个拓扑结构。拓扑结构包括可被并发地使用的资源(传感器和/或处理引擎)、它们的设置以及它们的连接的兼容组合。在给定时刻，多个拓扑结构可以是可能的。作为一个示例，第一拓扑结构可只包括以最大数据传输速率操作的硬件传感器210。根据以上示例，硬件传感器210可以是以4K来操作的相机。作为另一示例，第二拓扑结构可包括互连且使用允许资源互操作的设置来配置的硬件传感器210和220以及处理引擎240。根据以上示例，硬件传感器210和220可以是以720p操作的相机，处理引擎240可以是深度流引擎，并且传感器210和220可以与引擎240互连以便生成深度图242。第一拓扑结构和第二拓扑结构是不兼容的，因为这两者不能并发地操作。然而，在传感器群200的任何资源被配置之前，这两个拓扑结构都是可能的。传感器群200可被使用来管理传感器群200内的资源的设置和连通性。因而，传感器群200可最初在配置之前发布这两个拓扑结构，并随后随着不同资源被配置而动态地调整所呈现的拓扑结构(例如，呈现兼容拓扑结构的较小子集)。

传感器群200的不同资源的相对位置关系可通过将资源称为另一资源的上游或下游来指示。最上游资源是生成源流的资源。使用源流的资源处于生成源流的资源的下游。生成源流的资源处于使用源流的资源的上游。一般而言，与较接近源流的设备相比，进一步远离源流的资源处于更下游。作为特定示例，处理引擎260在处理引擎240下游，处理引擎240在硬件传感器210下游。

处理引擎也可以是使用基于软件和硬件的组件的混合模块。可被用来对处理引擎进行分类的区分因素在于处理引擎接收流输入。例如，视频编码器可以是通过硬件加速的基于软件的组件。作为视频编码器的一个示例，视频编码器可包括接收未编码视频流(诸如来自相机)并输出经编码视频流(诸如MPEG4或H.264视频)的硬件加速器。视频编码器可被分类成处理引擎，即使它使用硬件，因为编码器接收流输入。

软件传感器(诸如软件传感器230)可包括用于生成流数据的软件例程。具体而言，软件传感器230可以生成数据流，而不消费来自硬件传感器的任何源流或来自处理引擎的合成流。软件传感器230可以是可生成或从非传感器源拉取数据的自定义源，诸如通过从网络拉取信息、从文件读取、或从软级例程或算法生成数据。

图3是示例计算机系统300的系统图。计算机系统300可包括各种硬件组件，诸如多个传感器(诸如传感器310和320)、分布式存储器(312、322、350和380)、中央处理单元(CPU)340、图形处理单元(GPU)370、以及辅助存储360(诸如硬盘驱动器)。硬件组件可连接到底座330和/或由底座330封闭。作为一个示例，传感器310可以是装载在底座330上的左相机，且传感器320可以是装载在底座330上的右相机。作为另一示例，传感器310可以是装载在底座330上的前相机，且传感器320可以是装载在底座330上的后相机。传感器310和320可包括分别紧耦合至传感器310和320的嵌入式存储器312和322。例如，嵌入式存储器312和322可被用来存储图像、视频或其他流传输数据。

CPU 340可以与计算机系统的硬件组件直接通信，或经由计算机系统300的芯片组逻辑和/或桥(未示出)来通信。CPU 340可以执行被加载到系统存储器350中的程序。例如，CPU 340可以执行可被用来管理计算机系统300的资源的操作系统(OS)352。具体而言，OS352可被用来管理输入/输出设备和协处理器(诸如通过使用设备驱动程序353和/或其他例程来初始化并控制传感器310、320和GPU 370)，管理虚拟和物理存储器两者(诸如通过将程序从辅助存储360加载到存储器并管理程序与传感器310、320和GPU 370之间的数据传输)，管理程序的进程和/或线程，管理对存储的使用(诸如辅助存储360)，以及向程序和设备提供其他系统服务。进程是执行中的程序或软件例程。每一进程可包括存储器空间、寄存器、程序计数器、进程标识符、程序代码、堆栈、堆、数据段、进程状态、以及进程的其他会计信息。每一进程可包括一个或多个执行线程，其中每一线程与该进程的其他线程共享存储器空间，并且每一线程可具有专用线程标识符、程序计数器、堆栈以及寄存器集合。CPU 340可以使用分时模式和/或并发地执行不同进程和/或线程。

物理系统存储器350包括可由CPU 340寻址的易失性和/或非易失性计算机可读存储(诸如随机存取存储器(RAM)、只读存储器(ROM)、闪存)。物理系统存储器350包括可使用每一位置的不同地址来访问的有限数目的存储位置。OS 352可以分配并寻址比物理存储器350中可用的更多的存储器位置。具体而言，OS 352可以分配和管理具有超出物理存储器350的物理地址范围的地址范围的虚拟存储器。作为一个示例，OS 352可以向每一进程或应用分配单独的虚拟存储器空间，使得多个虚拟地址空间可以并发地活跃。虚拟地址可使用OS 352的存储器管理软件和CPU 340的存储器管理硬件(诸如转换后备缓冲器(TLB))被映射到物理地址。具体而言，虚拟存储器地址可被分成各个页，并且普遍使用的页可被存储在物理存储器350中(活跃或常驻页)，且较不普遍使用的页可被存储在辅助存储360中(不活跃或非常驻页)。辅助存储360可具有比系统存储器350更慢的访问时间，所以通过将更普遍访问的页保持在系统存储器350中，存储器访问时间可被降低且系统300的性能可被提高。

系统存储器350可被用来存储可由CPU 340执行的程序(例如，软件代码、例程、模块、引擎、或指令)、数据结构、变量、数据缓冲区、以及其他信息中的全部或部分。如所解说的，存储器350加载有OS 352、传感器群对象354、应用356和358以及数据缓冲区359。传感器群354可被用来标识和管理硬件传感器310和320以及任何处理引擎或软件传感器。例如，传感器群354可以标识底座330内可用的所有传感器及它们相关联的处理引擎。应用356和358可以是能够由CPU 340执行的通用应用。如下文进一步更详细地描述的，应用356和358可包括生成流传输数据的生产者应用、接收或消费流传输数据的消费者应用、可控制传感器310和320的初始化和/或操作并阻挡其他应用控制传感器310和320的控制应用、和/或可初始化和/或使用传感器310和320但可被控制应用阻挡的共享应用。缓冲区359可由应用356、358以及传感器310和320来使用以传输数据。作为补充或替换，传输缓冲区可分别驻留在传感器310和320的嵌入式存储器312和322中以及与GPU 370相关联的图形存储器380中。

图4是用于使用传感器群442的示例软件体系结构400的系统图。操作系统410可以管理应用程序的执行、管理各应用程序之间的信息交换、以及向各应用程序提供服务，诸如通过提供到硬件传感器的接口。OS 410还可使用传感器群442来发现并配置传感器群442的资源，以及管理数据从传感器群442的资源到应用程序的传输。

OS 410可以将存储器分成与不同特权水平相对应的不同空间，其中较高特权进程具有对存储器和服务的较多访问，而较低特权进程具有对存储器和服务的较少访问。例如，OS 410可以将存储器分成用户空间420和内核空间430。应用(诸如应用450和460)以及较低特权软级例程可以在用户空间420中操作，且OS 410的较高特权服务可以在内核空间430中操作。将存储器分成用户空间420和内核空间430可以通过限制潜在故障或恶意应用的存储器访问来提高OS 410的安全性、隐私性、以及容错。

OS 410可包括用于管理程序执行的不同方面的不同软件例程、模块或组件。例如，OS 410可包括用于管理流传输数据的流服务器440、用于管理虚拟和物理存储器的存储器管理器480、用于管理图形存储器的图形存储器管理器490、以及用于初始化和管理硬件传感器的传感器驱动程序470。例如，存储器管理器可被用来在新进程开始时创建用于该进程或应用的虚拟存储器空间、分配虚拟存储器应用于各种目的、以及将虚拟地址映射到辅助存储中的物理地址和/或位置。存储器管理器可以使用页表来跟踪虚拟到物理映射。存储器管理器通常只使用位于系统存储器内的紧耦合至CPU的物理存储器。图形存储器管理器490来使用存储器管理器480，除了图形存储器管理器490与紧耦合至GPU的图形存储器联用之外。因而，图形存储器管理器490和存储器管理器480在物理存储器的不同非交叠部分上操作。

传感器驱动程序470可由OS 410使用来与硬件传感器通信。为易于解说，示出了单个传感器驱动程序470，但可存在多个传感器驱动程序，诸如用于计算机系统的每一类型的传感器的传感器驱动程序。传感器驱动程序470可被用来初始化和/或更新传感器的寄存器，以使得传感器可被控制。传感器驱动程序470可被用来读取传感器的寄存器，以使得OS410知悉何时可从传感器获得数据。传感器还可在该传感器内具有用于存储该传感器收集的数据的嵌入式存储器，并且传感器驱动程序470可被用来管理数据从嵌入式物理存储器到OS 410的传输。

流服务器440可以使用传感器群442来管理传感器的配置和来自传感器的数据的传输。例如，流服务器440可包括用于管理数据传输的传输组件444和用于管理传感器的配置的配置组件446。另选地，传输组件444和配置组件446可被集成到传感器群442。例如，传输组件444和配置组件446可以是传感器群对象442的方法。

配置组件446可以管理对传感器群442内的资源(例如，传感器或设备或处理引擎)的不同访问和控制水平。例如，应用可以请求对传感器群的资源的不同类型的访问，且传感器群可以允许或拒绝该特定类型的访问。访问类型或模式可包括控制访问和共享访问。例如，应用可请求以控制模式来使用传感器群内的给定设备。如果应用被授予控制模式访问，则该应用在传感器群所允许的能力内具有对设备的配置的控制权。一旦应用被授予控制模式访问，则其他应用不能改变该设备的配置。因而，一旦控制模式访问被授予给一设备，传感器群内的一些潜在拓扑结构可能是不可达到的。例如，如果第一应用获得对右相机的控制模式访问且被授予4K比特率，则稍后应用将不能使用深度组件，因为右相机的输出速率不能被降至720p。通过授予控制模式访问，阻止了右相机的比特率降低。控制模式访问可以在先到先服务算法的基础上来授予，其中在给定时间段期间仅一个请求者可以是控制者。作为补充或替换，可使用不同方案来授予控制模式访问，诸如通过向应用给予不同优先级或特权水平并允许较高特权应用从较低特权应用接管控制。

控制模式访问可以影响传感器群442中的上游设备。例如，依存关系树可从控制设备开始来被构建，并且与相关流相关联的所有设备也可被锁定在控制模式中。例如，第一应用可请求以控制模式来使用深度组件。如果尚没有针对深度组件、左相机和右相机中的全部的控制应用，则可准予该请求。如果这些组件中的任一者已由不同应用锁定在控制模式中，则该请求将被拒绝。然而，如果所有组件都尚未被锁定在控制模式中，则该请求可被准予并且第一应用可以将所有这些组件锁定在控制模式中。传感器群442所发布的拓扑结构可被更新以反映拓扑结构中的一些可能归因于控制模式访问被授予而不再可用。

如果应用被授予共享模式访问，则其他应用可以在传感器群所允许的能力或拓扑结构内具有对设备的配置的控制权。因而，如果第一应用获得对右相机的共享模式访问且被授予4K比特率，则稍后应用可能够通过将右相机的输出速率降级至720p来使用深度组件。作为另一示例，如果第一应用得到对右相机的共享模式访问且被授予720p比特率，则得到控制模式访问的稍后应用可将右相机增至1080p。可以向第一应用通知该转变，并且第一应用可以接收该流丢失的消息。如果它通过请求更高的1080p比特率来重新加入该流，则第一应用可潜在地仍然使用右相机。

配置组件446还可被用来创建用于将数据从传感器传输到应用的缓冲区(例如，数据缓冲区454、464和474)。例如，在传感器首次使用时，可为该传感器创建进程(生产者进程)和虚拟存储器空间。生产者进程可被用来生产和管理来自传感器的数据传输并可包括传感器驱动程序470的软件例程。正在使用传感器数据的应用可以正在不同进程(消费者进程)中运行。例如，在应用请求使用传感器时，或响应于启动与该传感器相关联的应用，生产者进程可被创建作为计算机的初始化序列的一部分。物理存储器可被分配用于与该传感器相关联的数据缓冲区。具体而言，数据缓冲区可以在生产者进程的虚拟地址范围中分配，并且物理存储器可被映射到该虚拟地址范围。例如，可通过调用存储器管理器480、图形存储器管理器490和/或传感器驱动程序470的服务来分配存储器。因而，物理存储器可以是与CPU紧耦合的系统存储器、与GPU紧耦合的图形存储器、和/或与传感器紧耦合的嵌入式传感器存储器。来自每一页内的地址可被读出(或探测)并锁定在物理存储器中。锁定存储器包括将数据缓冲区的各页保持驻留在物理存储器中，以使得这些页不被页出(page out)到辅助存储。通过将物理存储器页指派给消费进程的虚拟地址，物理存储器可以与调用方或消费方应用共享。因而，不同虚拟地址可以使得相同物理地址。生产者虚拟地址、消费者虚拟地址以及物理地址的映射可被保持在存储器描述符列表或其他数据结构中。存储器描述符列表可以是有效存储器位置的数组或链表。

配置组件446还可被用来将库例程(例如，客户端管道接口452和462)加载到调用方应用的虚拟存储器以辅助从传感器到该应用的数据传输。例如，库例程可充当该应用与传感器之间的接口。具体而言，库例程可被用来访问传感器群442和/或流服务器440的服务、信息、和/或方法。

传输组件444可被用来管理从传感器到应用的数据传输。例如，数据缓冲区可被安排成具有指向最旧信息的头部和指向最新信息的尾部的循环先入先出(FIFO)缓冲区。生产者进程可以通过将数据推入缓冲区的尾部来添加信息，而消费者进程可以通过从缓冲区的头部拉出数据来从缓冲区取得信息。缓冲区是循环式的，所以在存储位置中的数据已被消费之后，存储位置可被重用。多个消费者进程可以从缓冲区拉取，所以存储位置可能不被再循环，直至所有消费者进程从该位置拉取数据为止。如果进入缓冲区的传输速率大于从该缓冲区外出的传输速率，则该缓冲区将变得充满。传输组件444可以支持用于缓冲区的有损或无损办法。如果缓冲区被配置成无损，则在缓冲区充满时，来自生产者进程的新数据可被延迟或丢弃。如果缓冲区是有损的，则来自生产者进程的新数据可盖写当前未从缓冲区读出的最旧数据。缓冲区内数据的次序和位置可以用指向该缓冲区内的每一数据块的存储器描述符列表来跟踪。传输组件444可以通过向库例程(例如，客户端管道接口452、462)发送消息或通过对来自库例程的请求作出响应，来向应用指示缓冲区中数据可用。例如，在数据可用时，传输组件444可以向应用提供指向缓冲区的头部的指针(如从存储器描述符列表确定的)。

为了概括以上概念中的一些概念，图4的示例解说了OS 410可正在执行两个分开的应用，控制应用450和共享应用460。应用450和460中的每一者可以是分配其自己的虚拟存储器空间的单独进程。传感器驱动程序470可以正在第三虚拟存储器空间中运行。作为一个示例，控制应用可以向流服务器440发送使用传感器群442所标识的一个或多个传感器的请求。该请求可以使配置组件446创建用于传感器驱动程序470的进程，加载客户端管道接口452，以及创建缓冲区474和454。缓冲区474和454在不同虚拟存储器空间中，但可以参考相同物理存储器，这可以是系统存储器、图形存储器和/或嵌入式系统存储器。传感器驱动程序470可以管理数据缓冲区474的填充并且在新数据可用时通知传输组件444。传输组件444可以与客户端管道接口452通信，以使得数据缓冲区454中的数据能被访问。应当注意，应用450可以访问和处理数据而无需将数据复制到另一物理存储器位置，因为数据被直接映射到该应用的虚拟地址空间并且数据驻留在物理存储器中(通过锁定与数据缓冲区相对应的存储器位置)。以此方式，与数据从物理存储器中的一个范围复制到物理存储器中的另一范围的情况相比，数据从传感器到应用450的“传输”可以用减少的时间量并且使用更少的存储器资源来被访问。在数据正被传输时，共享应用可以向流服务器440发送使用与控制应用450正在使用的相同流输出的请求。流传输可由传感器群442来标识。因为传感器驱动程序470已经运行，且缓冲区454已被分配，所以该请求可以使配置组件446加载客户端管道接口462并创建缓冲区464(例如，找出空闲虚拟存储器地址位置，并将它们映射到与缓冲区474相对应的物理存储器)。因而，缓冲区474、464和454可全部在不同虚拟存储器空间中，但可参考相同物理存储器。

应当注意，为易于解说，以上描述仅描述了用户空间420与内核空间430之间的功能性的一种划分。然而，其他划分是可能的。作为一个示例，传感器群对象442可被指派给用户空间420或内核空间430。同样，以上描述仅描述了OS 410的软件功能的一种组织。例如，传感器群对象442可以使流服务器440的一部分，或者传感器群对象442可以与流服务器440分开但与其通信。

示例传感器群方法

图5-7解说了使用虚拟化传感器群的示例方法。图5是解说管理与传感器群相关联的资源的示例方法500的流程图。在510，标识或枚举能够被编组在传感器群中的资源以创建该传感器群的成员资格。例如，资源可包括硬件传感器、软件传感器、以及处理引擎。资源的能力也可被枚举。例如，每一资源可包括能被并发地利用或与其他应用互斥地利用的一组能力。作为一个示例，传感器群的各个体传感器可以基于到处理引擎的连接或基于来自控制的输入按不同性能水平来操作。

在一个实施例中，传感器群内的成员资格可基于与给定容器标识符相关联的硬件传感器、相应传感器可用的简档信息、以及所安装的软件组件来定义。作为一个示例，传感器群可包括具有匹配的容器标识符的硬件传感器。容器标识符可被用来标识其上装载硬件传感器的特定物理底座。例如，内置到膝上型设备内的多个相机可以共享同一容器标识符，因为膝上型设备表示物理底座。(诸如经由USB端口)插入到膝上型设备的多相机设备可具有跨这些相机的共同容器标识符，但可具有与内置相机不同的容器标识符，因为多相机设备的物理底座可以使被插入到膝上型设备的物理容器。容器标识符可被存储在硬件传感器的寄存器或存储器中。例如，容器标识符可被存储在硬件传感器的闪存或只读存储器中。作为补充或替换，容器标识符可被存储在与硬件传感器相关联的驱动程序或其他软件中。

作为另一示例，可能需要特定简档信息以使给定传感器绑定在传感器群内。例如，简档信息可被存储在与给定传感器相关联的设备驱动程序或预定义文件类型中。在给定传感器被添加到计算设备时，简档信息可被存储或安装在计算设备上。例如，相机传感器可以在相机简档和/或并发相机简档中描述。例如在相机传感器被添加到计算机时，相机简档和并发相机简档可被安装。简档可被用来描述传感器支持哪些能力和/或哪些传感器能一起工作。例如，相机可以支持不同能力，包括一组所支持的捕捉分辨率、用于视频捕捉的帧率、以及是否支持高动态范围成像(HDR)或可变帧率捕捉。该组能力可以在预定义数据结构中捕捉，诸如由通用视窗平台(UWP)媒体捕捉框架所定义的。例如，相机简档可由具有三个媒体描述集合的软件对象来表示：一个用于相片捕捉，一个用于视频捕捉，以及又一个用于视频预览。作为另一示例，并发相机简档可以指定相机的相对取向，诸如左相机、右相机、前相机或后相机。并发相机简档可以指定一起使用相机的限制，诸如如果存在共享硬件组件(诸如帧缓冲器)的话。并发相机简档可指定与该相机有关的附加信息，诸如作为温度、取向等的函数的相机性能特性。

作为另一示例，任何预安装软件组件可被添加到传感器群。例如，默认地，处理引擎和软件传感器可属于所有容器标识符，并且具有与所有硬件传感器共同的并发相机简档。另外，在新软件被安装在计算机上时，软件组件可被添加到传感器群。例如，软件安装可触发传感器群的枚举。

枚举可发生在计算设备的引导序列期间和/或与传感器群相关联的进程苏醒时。例如，可在用来存储与计算设备的设备和软件相对应的设备密钥或软件密钥的数据库(诸如注册表或设备接口节点)中搜索各设备。如果存在新设备或如果先前安装的设备未被找到，则可发起传感器群的枚举和拓扑结构协商。在枚举之后，设备和处理单元的列表可被散列化，并且散列结果可被存储。在下一枚举期间，设备和处理单元的列表可被散列化，并且散列结果可与所存储的散列结果相比较。如果散列结果不同(指示该组设备已改变)，则可发起拓扑结构协商。然而，如果散列结果相同(指示该组设备没有改变)，则可跳过拓扑结构协商。

在520，可以确定所枚举的资源的兼容的拓扑结构，诸如通过执行拓扑结构协商。单个拓扑结构可以表示资源可在传感器群内连接和配置的一种方式。拓扑结构的完整集合可列出资源可在传感器群内连接和配置的所有不同方式。一些拓扑结构可能不与其他拓扑结构兼容。例如，通过选择一种拓扑结构，其他拓扑结构可被排除，因为不同拓扑结构的设置和/或配置可能是不兼容的。可通过使用处理引擎的依存关系来确定处理引擎需要哪些资源(例如，输入和能力)，以确定不兼容性。仅当特定资源的所有上游资源都可用时，拓扑结构才可包括该资源。在传感器没有安装时或者当上游传感器已按不兼容方式配置时，上游资源可能不可用。因而，传感器群内的可用拓扑结构可随着传感器和/或处理引擎被配置使用而改变。

拓扑结构协商可被用来确定哪些传感器和流可供用于传感器群以及流的哪些组合是可操作的。拓扑结构协商能以数个规则来开始，诸如：所有硬件传感器和软件传感器可生产源流；处理引擎可生产一个或多个合成流并可具有一个或多个相关流；所有源流和所有合成流可作为可用流的列表提供给系统上的每一处理引擎，直至合成流的集合完成(例如，基于处理引擎的可用列表，直至没有新合成流可用)。这些规则旨在是拓扑结构协商的规则的类型的解说，并且附加(或更少)规则是可能的。

传感器群是可基于给定系统上的可用硬件/软件来动态地发现的。例如，每当新视频捕捉设备(例如，相机设备)或处理引擎被添加或从系统移除时，可用拓扑结构可被更新并由传感器群发布。这可以通过迭代所有可用硬件/软件传感器并与每一组件协商来获得可用资源流的列表来完成。

传感器群可发布可由应用使用的潜在拓扑结构的集合。发布拓扑结构可包括提供传感器群访问拓扑结构的方法或字段，将拓扑结构写入存储器中的数据结构和/或存储设备上的文件。在传感器群的资源被配置在控制模式中时，拓扑结构中的一些可不与该配置兼容并且不兼容的拓扑结构可从所发布的拓扑结构集合中丢弃。然而，在传感器群的资源被配置在共享模式中时，资源可以按不同方式重新配置，并且所以所发布的拓扑结构集合可保持与配置之前相同。换言之，所发布的拓扑结构可包括与配置在共享模式中的资源不兼容的拓扑结构，因为该资源可被重新配置。

应用可具有对多个传感器群的并发访问。例如，可为每一可用物理容器(包括由计算机——例如，膝上型设备、台式机，等等——表示的基础底座)以及针对该物理容器上可用的传感器中的每一者定义的每一并发相机简档，自动生成不同传感器群。

在530，可接收配置所枚举的资源中的至少一者的请求。通过向传感器群发出请求，应用可以使用传感器群对象来保留流和/或配置传感器群内的拓扑结构。该请求可包括请求者的进程标识符，授权令牌，模式(例如，控制或共享)，流标识符，资源标识符，拓扑结构标识符，容器标识符，流类型，资源类型或能力，缓冲区大小，或用于选择和/或配置传感器群的资源的其他信息。例如，该请求可以针对特定资源或针对与一组能力相匹配的资源。作为特定示例，该请求可以针对左相机(或源自左相机的特定源流)或能以1080p操作的任何相机(或源流)。通过标识左相机，只有一个资源可匹配该请求。然而，通过标识能够以1080p操作的任何相机，操作系统可在可满足所请求的能力的多个资源之间选择。

操作系统可以选择最佳地适配优化准则的拓扑结构或资源。例如，OS可以选择已经工作的相机，使得与必须两个不同相机(以及两个不同缓冲区)执行同一功能相比，存储器占用和能量使用可被降低。作为另一示例，OS可以从一群较低保真度相机中选择较高保真度相机，使得与相机相关联的用户体验可潜在地被增强。以此方式，传感器群的资源可被虚拟化，更像虚拟存储器，其中OS可以选择与一组能力相匹配的特定物理资源。该组能力可以在对传感器群的请求中被完全枚举，或者该组能力可由传感器群基于优化准则和可用资源和/或拓扑结构来填充或完成。

传感器群还可通过将传感器群的各个体组件组合成可使用单个接口访问的单个编组来提供虚拟化。具体而言，传感器群可以提供可被并发地使用的各个体组件的一组有效组合。因而，应用可以按与针对单个物理传感器的相同方式与传感器群交互。例如，单个物理传感器可以生成多个流，且单个传感器群可以生成多个流。传感器群可以通过将多个物理相机、处理引擎和软件传感器虚拟化成单个虚拟“设备”(它可基于传感器群内的传感器的数目和连通性来产生数个数据流)来扩展物理传感器模型。作为特定示例，传感器群可包括左和右RGB相机以及深度流处理引擎。作为另一特定示例，传感器群对象可包括左和右RGB相机、红外相机、以及深度流组件。

在540，可以对请求执行一个或多个检查。作为一个示例，请求的各元素可被检查以确定这些元素兼容所发布的拓扑结构。具体而言，该请求可被检查以确定有效模式、拓扑结构、流、媒体类型、传感器或其他元素是否被请求。作为另一示例，该请求的授权令牌可以与所保存的关联于该资源的授权令牌相比较。具体而言，OS的传感器驱动程序和/或服务可以只向被授权访问特定资源的程序发出令牌。请求者可以在发出请求之前或响应于访问传感器群来获得令牌。如果请求的检查中的任一者失败，则在550，可响应于该请求来发送出错消息。然而，如果该请求的检查成功，则方法500可在560处继续。

在560，可根据该请求来配置资源。该配置可针对单个资源或针对多个资源。例如，如果请求配置合成流，则可以标识生成该流的处理引擎的依存关系，并且可相应地配置相关流和资源。该配置可基于资源在请求时是否已经在使用中而不同。例如，如果资源没有在使用中，则该配置可包括改变传感器的功率状态(例如，通电)、启动与该资源相关联的新进程、更新所发布的传感器群的拓扑结构、分配虚拟和物理存储器以创建数据缓冲区、探测和锁定存储器以将它固定在物理存储器中、对传感器的寄存器进行写入以配置和/或启动传感器、和/或使用就绪消息和/或与数据缓冲区相对应的虚拟地址范围(在请求者的地址空间中)对该请求作出响应。如果该资源已在使用中，则该配置可基于请求要在控制模式还是共享模式中使用该资源而变化。例如，如果该请求要在控制模式中使用该资源，并且该配置与资源的当前配置不同，则可以从当前配置更改资源的配置。作为特定示例，配置可包括通过释放现有存储器或分配附加存储器(物理和虚拟)来重新确定数据缓冲区的大小，探测并锁定任何新分配的存储器，对传感器的寄存器进行写入以重配置和/或重启该传感器，更新所发布的传感器群的拓扑结构，向资源的其他用户通知该重配置，和/或使用就绪消息和/或与数据缓冲区相对应的虚拟地址范围(在请求者的地址空间中)对请求作出响应。然而，如果该请求是以控制模式来使用资源且配置与该资源的当前配置相同，则该资源的配置可以类似于共享模式中该资源的配置。例如，指派请求者地址空间中的虚拟存储器地址以提供对现有数据缓冲区的访问，和/或使用就绪消息和/或与数据缓冲区相对应的虚拟地址范围对请求作出响应。因而，与不共享资源相比，在各进程之间共享资源可更高效。具体而言，经共享资源可潜在地使用较少CPU周期、较少存储器以及较少能量来配置。

在570，所配置的资源可被用来传输数据。例如，传感器群的传感器可以生成能被存储在与该资源相关联的数据缓冲区中的数据。与该资源相关联的生产者进程可以监视该数据缓冲区，并更新存储指向缓冲区中存储的有效数据的指针的存储器描述符列表。有效数据可以是已被写入缓冲区且没有被向该资源请求数据的全部消费者进程读取的数据。在全部消费者进程都读取了该数据时，存储位置可通过将该位置从存储器描述符列表中移除来再循环。数据可使用有损或无损方法被存储在缓冲区中，以处置生产者进程与消费者进程之间的传输速率失配。

在580，可接收停止使用或拆毁该资源的请求。停止请求可例如来自生产者进程、消费者进程、或OS内核。对该请求的响应可取决于该请求的内容而不同、哪一进程发起了该请求以及该资源是否正被共享。例如，OS内核和/或生产者进程可以创建阻塞消费者进程中的全部或部分免于访问该资源的请求。以此方式，生产者和/或内核可保留对该资源的命令和控制，以潜在地增加用户的安全性和/或隐私性。内核和/或生产者可请求拆毁共享资源或向该资源的一部分消费者(例如，单个消费者)阻塞共享资源。另外，消费者可请求停止使用共享资源。在这些情形中，资源可继续操作用于未被阻塞的那一部分消费者。然而，对于被阻塞的那一部分消费者，与经阻塞消费者的数据缓冲区相关联的虚拟存储器可被解除映射，以使得对该存储器范围的将来请求可造成访问违反。另选地，资源可具有单个消费者，或者可以请求阻塞该资源的所有消费者。如果该资源的所有消费者都要被阻塞，则该资源可被停止或拆毁。

在590，可停止或拆毁该资源。停止该资源可包括中止与该资源相关联的生产者进程，中止与该资源相关联的服务，释放和解锁存储器(虚拟和物理)以使得该存储器可由OS重用，改变传感器的功率状态(例如，将传感器置于低功率或断电模式)，向消费进程通知该资源正被停止，更新所发布的传感器群的拓扑结构，和/或使用指示该资源正在停止的通知消息来对该请求作出响应。

图6是解说分配计算系统的资源的示例方法600的流程图。在610，可枚举能够彼此交互的硬件传感器和软件模块。枚举可包括标识具有匹配容器标识符的所有硬件传感器。枚举可包括标识在数据块或文件(诸如并发相机简档文件)中注册的所有硬件传感器和软件模块。软件模块可包括能生成源流的软件传感器和能使用输入流来生成合成流的处理引擎。枚举可响应于计算系统的初始化序列(诸如引导序列)来发生。枚举可响应于添加或卸载传感器或处理器引擎来发生。

在620，可协商与所枚举的硬件传感器和软件模块的能力相兼容的拓扑结构。拓扑结构协商可包括标识软件模块中的每一者的相关流(以及传输速率)、相关资源、和/或相关模式。拓扑结构协商可包括标识硬件传感器的共享资源(诸如一对相机的共享帧缓冲器)。协商拓扑结构可包括找出所枚举的硬件传感器和软件模块的兼容的连接和设置集合，以使得可以生成合成流。经协商的拓扑结构可被添加到可由所枚举的硬件传感器和软件模块的潜在请求者访问的列表或数据结构。

在630，可从请求者接收配置所枚举的硬件传感器和软件模块中的至少一者的请求。该请求可以是按控制模式和/或共享模式来使用所枚举的硬件传感器和软件模块中的该至少一者。例如，该请求可以是按共享模式使用一个所枚举的资源以及按控制模式来使用一个所枚举的资源。作为特定示例，可以请求拓扑结构，其中请求红外相机处于控制模式中并且请求可见光谱相机处于共享模式中。作为另一示例，该请求可以针对处于共享模式的单个资源。该请求可以针对特定资源(例如，左可见光谱相机)或针对具有特定能力的资源(例如，任何可见光范围相机)。

在640，所枚举的硬件传感器和软件模块中的该至少一者可响应于接收到的请求根据经协商的拓扑结构来被配置。配置所枚举的硬件传感器和软件模块中的该至少一者可包括将请求者的地址空间中的虚拟存储器地址范围指派给数据缓冲区，将该虚拟存储器地址范围映射到计算系统的物理存储器。计算系统的物理存储器可以从与中央处理单元相关联的系统存储器、与图形处理单元相关联的图形存储器、或硬件传感器的嵌入式存储器中选择。配置所枚举的硬件传感器和软件模块中的该至少一者可包括启动与传感器驱动程序相关联的进程并将地址空间中的虚拟存储器分配给数据缓冲区。用于数据缓冲区的物理存储器可以在传感器驱动程序进程和请求者进程之间共享，以使得数据可被传输到请求者而无需复制该数据。

在650，所枚举的硬件传感器和软件模块中的该至少一者可任选地与附加请求者共享。具体而言，数据缓冲区可被指派给附加请求者的虚拟地址空间，并且物理存储器可以在生产者进程(与传感器驱动程序相关联的进程)和消费者或请求者进程之间共享。

图7是解说对传感器进行虚拟化的示例方法700的流程图。在710，可发布一组拓扑结构。拓扑结构可包括硬件传感器和/或软件模块的可互操作组合。发布可包括将拓扑结构写到储存在存储器中的文件或数据结构。发布可包括提供传感器群对象的方法以用于标识拓扑结构。用于发布的拓扑结构可通过枚举传感器群的资源并基于资源的依存关系标识资源的兼容组合来确定。

在720，可以从消费者进程接收使用所发布的一组拓扑结构中的特定拓扑结构的请求。消费者进程可请求以控制模式或共享模式来使用该特定拓扑结构的资源的全部或部分。该请求可以针对包括特定资源的拓扑结构(例如，包括左可见光谱相机的拓扑结构)或包括针对具有特定能力的资源的拓扑结构(例如，包括任何可见光范围相机的拓扑结构)。

在730，消费者进程的地址空间中的一组虚拟地址可响应于接收到使用特定拓扑结构的请求而被映射到一组物理地址。物理存储器可以从与中央处理单元相关联的系统存储器、与图形处理单元相关联的图形存储器、或硬件传感器的嵌入式存储器中选择。由该组物理地址寻址的物理存储器可被用作数据缓冲区以用于将数据从与传感器或软件模块(例如，处理引擎)相关联的生产者进程传递到消费者引擎。例如，生产者进程和消费者进程可以通过使数据缓冲区的物理地址以使得生产者进程的虚拟存储器来共享该数据缓冲区。

在740，响应于接收到来自与该消费者进程的不同的进程的请求，该消费者进程的地址空间中的该组虚拟地址可任选地从该组物理地址解除映射。例如，生产者进程或OS内核的另一进程可请求撤回该拓扑结构的资源中的至少一者的消费者进程的访问特权。以此方式，生产者进程和/或OS内核可以维持对资源以及它们相关联的数据缓冲区的使用的命令和控制。作为另一示例，消费者进程可能正在按共享模式使用资源中的至少一者，并且另一消费者进程可请求以不兼容当前配置的控制模式使用该资源(例如，传输速率可被增加至超过该消费者进程能处理的程度)。因而，归因于该资源的重配置，消费者进程可失去对该资源的访问。

所公开的技术的附加示例

在本文根据以上讨论的示例讨论了所公开的主题的附加示例。

在一个实施例中，一种方法可被用来分配计算系统的资源。该方法包括：枚举能够彼此交互的硬件传感器和软件模块；协商与所枚举的硬件传感器和软件模块的能力相兼容的拓扑结构；从第一请求者接收配置所枚举的硬件传感器和软件模块中的至少一者的第一请求；以及响应于接收到的第一请求根据经协商的拓扑结构来配置所枚举的硬件传感器和软件模块中的该至少一者。配置所枚举的硬件传感器和软件模块中的该至少一者可包括将一组地址锁定在计算系统的物理存储器中。用于执行该方法的计算机可读指令可被存储在计算机可读存储器中。

协商拓扑结构可包括确定软件模块的相关流和传输速率。配置所枚举的硬件传感器和软件模块中的该至少一者可包括分配第一进程地址空间中的虚拟存储器地址范围，并将该虚拟存储器地址范围映射到计算系统的物理存储器。计算系统的物理存储器可以从与中央处理单元相关联的系统存储器、与图形处理单元相关联的图形存储器、或硬件传感器的嵌入式存储器中选择。

第一请求可包括请求以控制模式来使用所枚举的硬件传感器和软件模块中的该至少一者，并且拓扑结构是响应于接收到第一请求来更新的。

另选地，第一请求可包括请求以共享模式来使用所枚举的硬件传感器和软件模块中的该至少一者。在这一情形中，该方法可进一步包括接收配置所枚举的硬件传感器和软件模块中的至少一者的第二请求。第二请求可包括以与第一请求的配置不兼容的控制模式来使用所枚举的硬件传感器和软件模块中的该至少一者的请求。该方法还可包括响应于接收到的第二请求来重配置所枚举的硬件传感器和软件模块中的该至少一者。该方法还可包括向第一请求者通知所枚举的硬件传感器和软件模块中的该至少一者正被重配置。

在另一实施例中，一个或多个计算机可读介质可存储计算机可执行指令，当由计算机执行时，计算机可执行指令使得计算机执行一种传感器虚拟化方法。该方法包括：发布包括硬件传感器和/或软件模块的可互操作组合的多个拓扑结构；接收来自第一进程的使用所发布的多个拓扑结构中的第一拓扑结构的第一请求；以及响应于接收到使用第一拓扑结构的第一请求，将第一进程的地址空间中的第一组虚拟地址映射到第一组物理地址。该方法还可包括响应于接收到使用第一拓扑结构的第一请求，探测并锁定第一组物理地址。该方法还可包括响应于第一请求来改变硬件传感器中的至少一者的功率状态。

第一组物理地址可对应于给定硬件传感器的嵌入式存储器。另选地，第一组物理地址可对应于与图形处理单元通信的图形存储器。另选地，第一组物理地址可对应于与中央处理单元通信的系统存储器。

该方法还可包括执行与第一拓扑结构相关联的生产者进程，第一组物理地址还被映射到生产者进程的地址空间中的第二组虚拟地址，以使得第一组物理地址被映射到第一组虚拟地址和第二组虚拟地址两者。

该方法还可包括：从第二进程接收使用所发布的多个拓扑结构中的第二拓扑结构的第二请求，第二拓扑结构与第一拓扑结构不兼容；响应于接收到第二请求，将第一进程的地址空间中的第一组虚拟地址解除映射；以及响应于接收到第二请求，将第二进程的地址空间中的第二组虚拟地址映射到第二组物理地址。例如，第一请求可以是共享模式请求，而第二请求可以是控制模式请求。

在另一实施例中，一种计算系统包括多个相机；系统存储器；以及与该多个相机和该系统存储器通信的处理器。处理器可被配置成：提供包括与多个相机兼容的一个或多个拓扑结构的传感器群数据结构；从第一进程接收根据一个或多个拓扑结构中的一个拓扑结构来配置该多个相机的请求；响应于该请求来配置该多个相机中的至少一个相机；分配进程的第一地址空间中的虚拟存储器，并在系统存储器中锁定与该虚拟存储器相对应的物理存储器；使得客户端库被加载到进程的第一地址空间中，客户端库包括用于封装与相机中的所述至少一者通信的功能；以及基于相机中的所述至少一者的配置来更新传感器群数据结构。

一个或多个拓扑结构中的拓扑结构可以指定来自多个相机的源流、来自传感器群的软件处理单元的合成流、以及多个相机与软件处理单元之间的兼容连接。客户端库可包括用于控制相机中的所述至少一者的曝光和聚焦的功能。处理器可被进一步配置成响应于该请求来启动与相机中的所述至少一者的设备驱动程序相关联的第二进程。

内核存储器反射的示例

传感器群可以调用OS的各种服务或功能来执行与传感器群相关联的功能。例如，传感器群可以调用内核存储器反射器服务来管理与传感器群的数据缓冲区相关联的动作。内核存储器反射可被用来将共享存储器(诸如来自相机的媒体帧)从单个生产者高效地映射到多个消费者。代替生产者/消费者进程将存储器映射到它们的进程空间，内核组件(本文称为反射器或内核存储器反射器)可以处置存储器的映射和寿命。这可通过生产者进程向反射器提供因该生产者进程而异的虚拟地址列表连同它们的大小和可消费该数据的消费者进程的列表来实现。内核存储器反射可被用作用于各种生产者/消费者存储器虚拟化方案(诸如传感器群)的基础。

如本文公开的，内核存储器反射可潜在地降低或消除复制并使生产者进程能维持访问控制。例如，代替生产者/消费者进程将存储器映射到它们的进程空间，内核反射组件处置存储器的映射和寿命。这可通过生产者进程向反射器提供因该生产者进程而异的虚拟地址列表连同它们的大小和可消费该数据的消费者进程的列表来实现。

因为生产者提供数据的经允许消费者的列表，所以反射器可以使用生产者提供的列表来确保任何非批准消费者不被允许访问经反射帧。换言之，生产者进程通过反射器进行通信以分配可由消费者进程访问的存储器。

反射器可以探测/锁定与虚拟地址相对应的物理存储器页，并且在所列出的消费者进程之一请求“数据帧”时，反射器可以将该物理存储器页“反射”到消费者进程的地址空间。这可以在发出请求的消费者已被确认为生产者所确定的已接受消费者之一之后完成。

反射器可以管理经反射存储器的生命周期，从而保持存储器常驻，直至消费者已指示它完成处理该帧或生产者已指示访问权限可能撤消。响应于这些事件之一，反射器可以从消费者进程地址空间移除经反射存储器。通过允许这一规程，物理存储器和该存储器到各消费者进程地址空间的对应“反射”的所有权可与反射器保持在一起。

此外，因为反射器可在由生产者进程提供的任何虚拟地址上工作，所以不需要使用区段对象或任何特定存储器类型。因而，由系统RAM支持的任何存储器可潜在地以此方式来反射。

反射器可被扩展以进一步处置非系统RAM，假定存在跨进程边界来编排非系统RAM存储器的机制(诸如NT HANDLE复制)。

使用内核存储器反射的示例方法

使用内核存储器反射的示例方法可始于消费者进程请求访问生产者进程的输出。在该请求的时刻，生产者进程可空闲或运行。例如，响应于消费者进程的请求，生产者进程可被启动、苏醒、或查询。该请求可包括所请求的访问的类型(例如，只读或读写)、与消费者进程相关联的凭证、缓冲区大小、和/或生产者进程地址空间内的虚拟地址范围。在生产者进程空闲或休眠时，与生产者进程的输出缓冲区相关联的存储器可被释放，以使得其他应用可以使用该存储器。

生产者进程可以确定是否向消费者进程给予对生产者数据的访问以及给予什么类型的访问。例如，可检索访问控制列表，并且如果消费者进程或与消费者进程相关联的用户具有使用生产者进程的许可，则消费者进程可被授予对生产者数据的访问。作为另一示例，该请求内的各属性可被分析，并且如果被请求的属性匹配生产者进程的能力，则消费者进程可被授予对生产者数据的访问。具体而言，如果消费者进程请求不支持的比特率或数据类型，则该请求可被拒绝。

生产者进程可使用堆分配程序(诸如“malloc”或“new”)、来自存储器池的分配、或其他分配过程来分配用于生产者进程的输出缓冲区的存储器。堆分配可提供不同大小的存储器块的分配，而存储器池分配可提供具有固定大小的存储器块的分配。通过分配用于输出缓冲区的存储器，生产者进程的地址空间内的虚拟地址范围与输出缓冲区相关联。输出缓冲区的虚拟地址可作为分配过程的一部分或在稍后时刻被映射到物理地址。另选地，生产者进程可以使用早先分配的相同存储器来用于输出缓冲区。例如，在第一消费者进程请求由生产者进程生成的数据时，存储器可被分配，并且在第二消费者进程请求该生产者进程生成的数据时，同一存储器的全部或部分可被使用。

生产者进程可以经由反射器配置到消费者进程的传输机制。例如，如果生产者进程确定它将向消费者进程给予对生产者数据的访问，则消息或请求可以从生产者进程发送到OS内核的反射器。该消息可包括对经批准消费者的引用(诸如进程标识符)以及给予该经批准消费者的访问等级(诸如，只读或读写)。反射器可以与生产者进程相关联地跟踪或注册经批准消费者进程。该消息可包括缓冲区大小、存储器的类型(例如，堆或池)、缓冲区的起始虚拟地址、和/或生产者进程存储器范围内的虚拟地址范围。生产者进程可以决定消费者进程将接收什么访问等级。例如，生产者进程可以向各个体消费者进程授予只读访问或写访问。作为特定示例，对于给定输出缓冲区，给定生产者进程可向一个消费者授予只读访问并向不同消费者授予读写访问。

反射器可以将与生产者进程的输出缓冲区相对应的虚拟存储器地址固定或锁定到物理存储器页。通过锁定物理存储器页，反射器可以防止存储器页被页出物理存储器，从而潜在地允许对各页的较低等待时间访问。反射器可以维持限额系统，以使得应用不能超出物理存储器的阈值量。阈值量可被选择成使得给定应用不能饿死也可请求存储器资源的其他应用。反射器可以维持或更新将虚拟存储器地址映射到物理存储器地址的存储器描述符列表。物理存储器地址可以是毗连或非毗连的。反射器可以在缓冲器的初始化期间将输出缓冲区的整个地址范围锁定到物理存储器，并保持存储器锁定达缓冲器的寿命。作为补充或替换，反射器可以随着生产者写入输出缓冲区来动态地锁定物理地址，并随着所有消费者从输出缓冲区读出来释放物理地址。例如，在给定视频帧的情形中，在视频帧被写入输出缓冲区时，与给定视频帧相对应的物理存储器可被锁定，并且在视频帧被从输出缓冲区读出时，物理存储器可被释放。

随着生产者进程生成数据，该数据可被写入输出缓冲区。数据的示例可包括来自视频相机或静止相机的帧缓冲区数据、来自话筒的音频数据、来自硬件或软件资源的流传输数据，等等。数据可以使用无损或有损办法传送通过缓冲器。作为一个示例，该数据可使用无损先入先出办法传送通过缓冲器。在这一办法中，在缓冲区充满时，诸如在消费者没有与生产者将数据放入缓冲区那样快地读出数据时，该缓冲区将停止(例如，没有新数据可被存储在缓冲区中)。先入先出办法可基于生产者和消费者的数据传输速率来调整。例如，存储在缓冲区中的最旧数据可首先从缓冲区中读出或盖写。如果存储在缓冲区中的数据的量达到限额或缓冲区变得充满并且生产者有更多数据要存储在缓冲区中，则生产者可使用新数据盖写最旧数据。这可在生产者将数据写入缓冲区比消费者从缓冲区读出数据更快时发生。通过盖写缓冲区中的最旧数据，最旧数据将丢失。换言之，数据可老化并且最旧数据可被首先移除，无论它由消费者读出还是由生产者盖写。在实时流传输中，诸如在从相机流传输视频帧时，有损缓冲区可能是合乎需要的。

生产者与消费者之间的握手可由反射器使用推和/或拉模型来管理。例如，生产者可以向反射器发送消息，指示数据块已被写入输出缓冲区并且准备好被消费。反射器可以将消息推送或发送到消费者，指示新数据在输出缓冲区中可用。该消息可被发送到数据的多个消费者。消费者可以向反射器指示何时从缓冲区读取该数据。在所有消费者已从缓冲区读取特定数据块时，与该块相对应的存储器可被盖写。推模型可更好地模仿驱动程序行为。拉模型也可被使用，其中在消费者准备好读取数据时，消费者向反射器请求数据。如果反射器在缓冲区中没有数据，则它可以用指示没有数据的消息对消费者作出响应。在一个实现中，推模型可被用作默认传输模式，而拉模型可以用在后退模式中。例如，推模型可以使用，直至输出缓冲区变得充满或包含阈值数据量。在缓冲区充满时，它可指示消费者当前不能以生产者向缓冲区添加信息的速率来处理数据。在缓冲区充满时，传输模式可切换至拉模型，其中消费者向反射器通知它准备好从缓冲区读取数据。缓冲区可按此方式排空，直至数据量落在阈值量之下或缓冲区变空。传输模式随后可返回推模型。

生产者进程可维持对经反射存储器的命令和控制。例如，生产者进程可以在任何时间撤消消费者进程的访问。生产者可通过向反射器发送具有请求解除分配存储器的消息来使该存储器被解除分配。反射器可向输出缓冲区的任何经注册消费者发送存储器已被解除分配的消息。因而，消费者可采取动作来防止从无效指针读取数据。另选地，在数据的所有消费者指示它们完成处理该数据时，存储器可由反射器解除分配。解除分配的存储器可由内核或其他进程重用。

通过允许生产者进程维持对经反射存储器的命令和控制，共同拥有的共享存储器的缺陷中的一些可能被避免。例如，共同拥有的共享存储器可由数据的消费者和生产者两者来拥有。因而，消费者可具有对数据的读/写访问，且消费者可能潜在地破坏该数据。存储器管理器还将认识到，消费者共同拥有共享存储器，所以即使生产者尝试将该存储器解除分配，只要消费者是共同所有人，该存储器也不能被解除分配。例如，在消费者具有指向共享存储器空间的句柄或指针时，垃圾收集程序可被阻止重用该存储器。因而，可造成存储器泄漏，并且计算机的存储器资源可被不良地利用，这可归因于存储器不足而阻止一些服务正确地工作。此外，存储器泄漏是共享服务的，这可潜在地造成不同进程之间的隐私问题。

附加反射示例

一种示例计算系统可包括由多个应用使用的相机。该计算系统可包括一对应用，诸如用于使用指纹或脸部识别来登录到计算机的登录程序以及视频会议应用。该系统可包括RGB相机和IR相机。对于登录程序，IR相机可被用于识别，且RGB相机可被用于反欺诈。IR相机可以处于控制模式中，而RGB相机可以处于共享模式中。对于视频会议应用，RGB相机可以处于控制模式，而IR相机可以处于共享模式。例如，RGB图形可以是视频的主图像，而IR数据可被用于模糊和/或聚焦RGB图像。每硬件设备只允许单个消费者的典型OS将需要两组RGB和IR相机才能使这两个应用同时运行。使用内核反射，相机(或相机的软件模块)可以允许多个消费者使用相机数据并且可控制哪些应用具有哪些类型的访问。例如，与RGB相机相对应的生产者进程可以向登录应用授予一种类型的访问，而向视频会议应用授予不同类型的访问。类似地，与IR相机相对应的生产者进程可以向登录应用授予一种类型的访问，而向视频会议应用授予不同类型的访问。

示例计算环境

图8解说了其中可实现所描述的实施例、技术和工艺(包括支持传感器虚拟化)的合适计算环境800的通用示例。

计算环境800不旨在对本公开技术的使用范围或功能性提出任何限制，因为本公开技术可以在完全不同的通用或专用计算环境中实现。例如，所公开的技术可以与其他系统配置一起实现，包括手持式设备、多处理器系统、可编程消费电子产品、网络PC、微型计算机、大型计算机，等等。所公开的技术也可以在任务由通过通信网络链接的远程处理设备执行的分布式计算环境中实现。在分布式计算环境中，程序模块(包括用于基于块的指令块的可执行指令)可位于本地和远程的存储器存储设备两者中。

参考图8，计算环境800包括至少一个基于块的处理单元810和存储器820。在图8中，这一最基本配置830被包括在虚线内。基于块的处理单元810执行计算机可执行指令，并且可以是真实或虚拟处理器。在多处理系统中，多个处理单元执行计算机可执行指令以提高处理能力，并且如此，多个处理器可同时运行。存储器820可以是易失性存储器(例如，寄存器、高速缓存、RAM)、非易失性存储器(例如，ROM、EEPROM、闪存，等等)或两者的某一组合。存储器820存储可例如实现本文公开的技术的软件880、图像以及视频。计算环境可具有附加特征。例如，计算环境800包括存储器840、一个或多个输入设备850、一个或多个输出设备860、以及一个或多个通信连接870。诸如总线、控制器或网络之类的互连机制(未示出)互连计算环境800的多个组件。一般而言，操作系统软件(未示出)为计算环境800中执行的其他软件提供操作环境，并且协调计算环境800的各组件的活动。

存储840可以是可移动或不可移动的，并包括磁盘、磁带或磁带盒、CD-ROM、CD-RW、DVD或可用于储存信息并可在计算系统800内访问的任何其他介质。存储840存储用于软件880的指令、插入数据、以及消息，这可被用来实现本文描述的技术。

(诸)输入设备850可以是诸如键盘、按键板、鼠标、触摸屏显示器、笔或轨迹球之类的触摸输入设备、语音输入设备、扫描设备、或者向计算环境800提供输入的另一设备。对于音频，输入设备850可以是接受模拟或数字形式的音频输入的声卡或类似设备，或向计算环境800提供音频样本的CD-ROM读取器。(诸)输出设备860可以是显示器、打印机、扬声器、CD刻录机或提供来自计算环境800的输出的另一设备。

(诸)通信连接870允许在通信介质上(例如，连接网络)到另一计算实体的通信。通信介质在已调制数据信号中传达诸如计算机可执行指令、经压缩图形信息、视频、或其他数据之类的信息。通信连接870不限于有线连接(例如，兆比特或吉比特以太网、Infiniband、电或光纤连接上的光纤信道)，而是还包括无线技术(例如，经由蓝牙的RF连接、WiFi(IEEE802.11a/b/n)、WiMax、蜂窝、卫星、激光、红外)以及用于向所公开的代理、桥和代理数据消费者提供网络连接的其他合适的通信连接。在虚拟主机环境中，通信连接可以是由虚拟主机提供的虚拟化网络连接。

所公开的方法的一些实施例可使用在计算云890中实现所公开的技术的全部或部分的计算机可执行指令来执行。例如，所公开的编译器和/或基于块的处理器服务器位于计算环境830中，或者所公开的编译器可以在位于计算云890中的服务器上执行。在一些示例中，所公开的编译器在传统中央处理单元(例如，RISC或CISC处理器)上执行。

计算机可读介质是可在计算环境800内访问的任何可用介质。作为示例而非限制，对于计算环境800，计算机可读介质包括存储器820和/或存储840。如应容易理解的，术语计算机可读存储介质包括用于数据存储的介质(诸如存储器820和存储840)而非传输介质(诸如已调制数据信号)。

鉴于可应用所公开的主题的原理的许多可能的实施例，应当认识到，所示实施例仅是优选示例，并且不应认为是将权利要求的范围限制到那些优选示例。相反，所要求保护的主题的范围由后续的权利要求来界定。因此，我们要求保护所有落在这些权利要求的范围内的发明。

Claims (20)

1.一种分配计算系统的资源的方法，所述方法包括：

枚举能够彼此交互的硬件传感器和软件模块；

协商与所枚举的硬件传感器和软件模块的能力相兼容的拓扑结构，所述拓扑结构包括能被并发地使用的硬件传感器和/或软件模块、它们的设置以及它们的连接的兼容组合，所述硬件传感器和/或所述软件模块中的至少一者能在运行在所述计算系统上的多个不同的进程之间共享；

从第一请求者接收配置所枚举的硬件传感器和软件模块中的至少一者的第一请求；以及

响应于接收到的所述第一请求根据经协商的拓扑结构来配置所枚举的硬件传感器和软件模块中的所述至少一者。

2.如权利要求1所述的方法，其特征在于，协商所述拓扑结构包括确定所述软件模块的相关流和传输速率。

3.如权利要求1所述的方法，其特征在于，配置所枚举的硬件传感器和软件模块中的所述至少一者包括分配第一进程地址空间中的虚拟存储器地址范围，以及将所述虚拟存储器地址范围映射到所述计算系统的物理存储器。

4.如权利要求3所述的方法，其特征在于，所述计算系统的物理存储器是从以下中的一者或多者选择的：与中央处理单元相关联的系统存储器、与图形处理单元相关联的图形存储器、或所述硬件传感器的嵌入式存储器。

5.如权利要求1所述的方法，其特征在于，所述第一请求包括以控制模式使用所枚举的硬件传感器和软件模块中的所述至少一者的请求，并且所述拓扑结构是响应于接收到所述第一请求来更新的。

6.如权利要求1所述的方法，其特征在于，所述第一请求包括以共享模式使用所枚举的硬件传感器和软件模块中的所述至少一者的请求，并且其中所述方法还包括：

接收配置所枚举的硬件传感器和软件模块中的至少一者的第二请求，所述第二请求包括以与所述第一请求的配置不兼容的控制模式使用所枚举的硬件传感器和软件模块中的所述至少一者的请求；以及

响应于接收到的所述第二请求来重配置所枚举的硬件传感器和软件模块中的所述至少一者。

7.如权利要求6所述的方法，其特征在于，进一步包括：

向所述第一请求者通知所枚举的硬件传感器和软件模块中的所述至少一者正被重配置。

8.如权利要求1所述的方法，其特征在于，配置所枚举的硬件传感器和软件模块中的所述至少一者包括锁定所述计算系统的物理存储器中的一组地址。

9.一个或多个存储计算机可执行指令的计算机可读介质，当由计算机执行时，所述计算机可执行指令使得所述计算机执行一种传感器虚拟化方法，所述方法包括：

发布包括硬件传感器、软件模块或硬件传感器和软件模块两者的可互操作组合的多个拓扑结构，所述多个拓扑结构中的每一者包括能被并发地使用的硬件传感器和/或软件模块、它们的设置以及它们的连接的兼容组合，所述硬件传感器和/或所述软件模块中的至少一者能在运行在所述计算机上的多个不同的进程之间共享；

从第一进程接收使用所发布的多个拓扑结构中的第一拓扑结构的第一请求；以及

响应于接收到使用所述第一拓扑结构的所述第一请求，将所述第一进程的地址空间中的第一组虚拟地址映射到第一组物理地址。

10.如权利要求9所述的一个或多个计算机可读介质，其特征在于，所述方法还包括：

响应于接收到使用所述第一拓扑结构的所述第一请求，探测并锁定所述第一组物理地址。

11.如权利要求9所述的一个或多个计算机可读介质，其特征在于，所述第一组物理地址对应于给定硬件传感器的嵌入式存储器。

12.如权利要求9所述的一个或多个计算机可读介质，其特征在于，所述第一组物理地址对应于与图形处理单元通信的图形存储器。

13.如权利要求9所述的一个或多个计算机可读介质，其特征在于，所述方法还包括：

执行与所述第一拓扑结构相关联的生产者进程，所述第一组物理地址还被映射到所述生产者进程的地址空间中的第二组虚拟地址，以使得所述第一组物理地址被映射到所述第一组虚拟地址和所述第二组虚拟地址两者。

14.如权利要求9所述的一个或多个计算机可读介质，其特征在于，所述方法还包括：

从第二进程接收使用所发布的多个拓扑结构中的第二拓扑结构的第二请求，所述第二拓扑结构与所述第一拓扑结构不兼容；

响应于接收到所述第二请求，将所述第一进程的地址空间中的所述第一组虚拟地址解除映射；以及

响应于接收到所述第二请求，将所述第二进程的地址空间中的第二组虚拟地址映射到第二组物理地址。

15.如权利要求14所述的一个或多个计算机可读介质，其特征在于，所述第一请求是共享模式请求，并且所述第二请求是控制模式请求。

16.如权利要求9所述的一个或多个计算机可读介质，其特征在于，所述方法还包括：

响应于所述第一请求来改变所述硬件传感器中的至少一者的功率状态。

17.一种计算系统，包括：

多个相机；

系统存储器；以及

与所述多个相机和所述系统存储器通信的处理器，所述处理器被配置成：

提供包括与多个相机兼容的一个或多个拓扑结构的传感器群数据结构，所述的一个或多个拓扑结构中的每一者包括能被并发地使用的硬件传感器和/或软件模块、它们的设置以及它们的连接的兼容组合，所述硬件传感器和/或所述软件模块中的至少一者能在运行在所述计算系统上的多个不同的进程之间共享；

从第一进程接收根据所述一个或多个拓扑结构中的一个拓扑结构来配置所述多个相机的请求；

响应于所述请求来配置所述多个相机中的至少一个相机；

分配所述进程的第一地址空间中的虚拟存储器，并在所述系统存储器中锁定与所述虚拟存储器相对应的物理存储器；

使得客户端库被加载到所述进程的第一地址空间中，所述客户端库包括用于封装与所述至少一个相机通信的功能；以及

基于所述至少一个相机的配置来更新所述传感器群数据结构。

18.如权利要求17所述的计算系统，其特征在于，所述一个或多个拓扑结构中的拓扑结构指定来自所述多个相机的源流、来自所述传感器群的软件处理单元的合成流、以及所述多个相机与所述软件处理单元之间的兼容连接。

19.如权利要求17所述的计算系统，其特征在于，所述客户端库包括用于控制所述相机中的所述至少一者的曝光和聚焦的功能。

20.如权利要求17所述的计算系统，其特征在于，所述处理器被进一步配置成响应于所述请求来启动与所述相机中的所述至少一者的设备驱动程序相关联的第二进程。

Images