CN112784283A - 能力的管理方法和计算机设备 - Google Patents

Abstract

本申请提供一种能力的管理方法、装置以及计算机设备等，涉及操作系统中内核对象的权限管理，例如微内核架构中内核对象的权限管理。具体的，该方法在能力所有者的能力节点中存储两种类型的信息：用于指示能力授权出去的信息和用于指示被授权的能力的信息，通过记录这两种类型的信息建立了能力在授权者和被授权者之间的关联关系，在能力授权的过程中避免了能力的拷贝，在授权者放弃能力的过程中避免了能力的删除，从而在实现能力回收和授权的同时保证了确定性时延。该方法可以应用于智能手机系统或无人驾驶系统等。

Description

能力的管理方法和计算机设备

技术领域

本申请涉及计算机技术，尤其涉及一种能力的管理方法、装置以及计算机设备等。

背景技术

基于微内核的操作系统架构(简称微内核架构)可以应用在云平台、嵌入式设备、移动设备、辅助驾驶、无人驾驶等多种场景中。微内核架构将传统的操作系统内核(例如宏内核架构Linux)中的众多的组件，比如文件系统和网络协议栈等都放在用户态进程中运行，而将自己真正的内核功能减少到非常少。微内核架构包括用户态进程以及内核。用户态进程是运行在用户态的进程。内核负责管理关键资源，并为用户态进程提供服务，例如进程间通信、页表、中断控制等服务。用户态进程通过系统调用来向内核请求服务。由于内核资源和服务是关键性的，需要保证访问安全性，所以内核资源或服务的提供需要一种安全管理机制来约束。

内核使用内核对象对自己提供的资源或服务进行抽象。目前的微内核架构普遍采用基于能力(capability)的安全机制(下文简称为能力机制)来控制用户态进程对内核对象的访问。具体的，用户态进程通过系统调用来向内核请求访问内核对象，该请求首先会经过能力机制的权限检查，在权限检查通过后，内核才开始响应该请求。

能力机制中基本的概念是能力(capability)。能力是一种不可伪造的权限标签，它记录了内核对象的标识(例如编号或内存地址)，以及访问该内核对象的权限。能力机制中的权限检查意味着：若一个用户态进程(下述简称为进程)想要访问一个内核对象，内核需要检查该进程是否获得了该内核对象的能力，若该进程获得了该内核对象的能力，则可以按照该能力记载的权限访问该内核对象，反之，该进程不能访问该内核对象。一个进程可以获得多个不同的能力，表示该进程可以访问多个不同的内核对象。一个进程所获得所有能力被放在一个数据结构中，该数据结构被称作能力节点。进一步的，一个进程可以把它自己有权访问的内核对象共享给其他的进程，即能力授权。同时，该进程也可以随时取消自己或其他进程访问该内核对象的权限，即能力回收。

为了解决能力的授权与回收，业界普遍采用的是能力拷贝和删除机制。具体的，进程A(也称为授权者)若需要与进程B(也称为被授权者)共享内核对象O，则将自己的能力节点中该内核对象的能力C拷贝到进程B的能力节点中。这样，进程B就可以访问该内核对象O了。进程B还可以继续执行共享。另外在能力拷贝的过程中，可以减少能力中的权限。前述能力的拷贝也可以称为派生(derivative)。

能力回收包括两种情况：一种是授权者主动回收授权出去的能力，另一种是被授权者放弃能力。为了完成能力回收，还需记录前述派生关系，即能力C1派生自能力C，能力C2派生自能力C1。记录这种派生关系的数据结构被称作能力派生树。当授权者回收一个能力的授权时，所有派生自该能力的能力都要被删除。当被授权者主动放弃某个能力的授权时，需要删除其能力节点中的该能力。

现有技术虽然能够实现能力的授权和回收，但是却不能保证确定性的时延(deterministic latency)。具体的，由于能力存在拷贝，所以可能有多个能力指向同一个内核对象，所以当被授权者主动放弃一个能力的授权时，可能有两种情况：1.当该能力不是指向它包含的内核对象的最后一个能力时，只需把该能力从能力节点中即可；2.当该能力是指向该内核对象的最后一个能力时，不仅要把该能力删除，同时还要把该内核对象删除。否则，会导致内存泄漏，因为没有别的方式能访问到该内核对象了。由于以上不同情况下的耗时是不同的，这为确定性时延的分析带来了很大挑战。

发明内容

本申请提供一种能力的管理方法，并提供实现该方法的数据结构、装置、计算机程序产品(例如操作系统)、存储介质以及计算机设备等。本申请提供的管理方法能够保证能力被放弃时的确定性时延。

需要说明的是，本申请提供这种能力管理方法也可以称为权限管理方法、内核对象的管理方法、基于能力的内核对象管理方法、能力的回收方法等。

首先介绍一下可能出现的概念。

操作系统：管理计算机硬件与软件资源的系统软件，同时也是计算机系统的基石。操作系统需要处理如管理与配置内存、决定系统资源供需的优先次序、控制输入与输出设备、操作网络与管理文件系统等基本事务。操作系统还可以提供让用户与系统交互的操作界面。

内核：用来管理软件发出的数据输入与输出要求的程序，将这些要求转译为数据处理的指令并交由中央处理器(CPU)及电脑中其他电子组件进行处理，是现代操作系统中最基本的部分。

内核对象：是内核管理的信息的抽象，代表内核维护的各种信息，比如线程控制块、进程页表、进程通信信道等。内核对象作为一种数据结构，被存储在内核分配的一个内存块中。内核对象由内核直接访问。内核提供接口以允许用户态进程访问内核对象，并且使用权限控制机制来管理用户态进程对内核对象的访问。需要说明的是，用户态进程对内核对象的访问是间接的，是用户态进程调用接口后进入内核，由内核直接执行访问。

能力：用来表征某个内核对象的访问权限。能力中通常记载有两项信息：内核对象的标识以及访问权限。能力中内核对象就是该能力指向(或称引用)的内核对象。换句话说，该能力表示的就是该内核对象的访问权限。内核对象的标识可以为内核对象的内存地址或编号；访问权限可以为只读、读/写等。内核通过基于能力的安全机制来管理用户态进程对内核对象的访问。具体的，一个进程只有获得一个能力之后，才可以访问该能力指示的内核对象，而且需要按照能力指示的权限进行访问。现有的微内核系统中通常将该能力命名为capability。

能力节点：是一个数据结构，用于存储一个进程获得的所有能力。能力节点本身也是一个内核对象。在微内核架构，例如L4系列的微内核架构中，该能力节点被命名为CNode(capability node)。所有的能力节点被存储在能力空间(capability space,CSpace)中。

能力授权(或称能力共享)：进程A拥有的能力可以共享给进程B，这样，进程B就可以访问该能力指示的内核对象。能力授权也可以称为内核对象授权。进程A可以称为授权者，进程B称为被授权者。现有技术中的能力授权是通过能力的拷贝(或称派生)实现的。应理解的是，这里的进程A和进程B通常都是用户态进程。能力的拷贝过程中可以修改权限，比如进程A可以选择性地仅将部分权限授权给进程B。

回收能力(或称回收授权)：进程A将授权给进程B的能力撤回，即不再共享该能力指示的内核对象。

放弃能力(或称放弃授权)：进程B放弃进程A授权给自己的能力。回收能力和放弃能力也可以统称为能力回收，看做是能力回收的两种不同的情况。

下面将从多个方面介绍本申请，容易理解的是，该以下多个方面可以单独实施，也可以选择其中任意两个或更多联合实施。该以下多个方面的实现和有益效果可互相参考。

第一方面，本申请提供一种用于管理能力的数据结构，该数据结构包括能力和能力的授权信息，所述能力包括内核对象的标识以及访问权限，所述能力的授权信息包括用于指示被授权的能力的第一信息和用于指示授权出去的能力的第二信息，所述第一信息和所述第二信息均不是能力。

在一些实现方式下，所述第一信息用于从所述被授权的能力的所有者的能力节点中查找到所述被授权的能力。所述被授权的能力仅存储在所述所有者的能力节点中。

在一些实现方式下，所述第二信息用于在所述第二信息所在的能力节点中查找到所述授权出去的能力。在一些实现方式下，所述第二信息中还包含授权出去的权限，该权限是授权出去的能力中的部分或全部权限。

在一些实现方式下，所述第二信息还用于指示所述授权出去的能力的被授权者。

在一些实现方式中，该数据结构可以作为一个内核对象存储在内核对应的存储空间中。具体的，该数据结构可以为能力节点。该内核可以为微内核。

在一些实现方式下，所述数据结构可以不包括所述第一信息，比如该数据结构存在于授权者的能力节点中或该数据结构是授权者的能力节点。在一些实现方式下，所述数据结构可以不包括所述第二信息，比如该数据结构存在于被授权者的能力节点中或该数据结构是被授权者的能力节点。

应理解的是，授权者和被授权者是相对的角色，两种角色可以互换。

在一些实现方式中，第一信息和第二信息可以是能力的标识，或存储能力的容器(例如slot)的标识(也可以理解为能力的存储地址)等。第一信息和第二信息用于查找到对应的能力，但第一信息和第二信息不是能力本身。

具体的，所述第一信息和所述第二信息可分别为图2中的M1和M2，或所述第一信息和所述第二信息可分别为图3中的M1和M2。

更具体的，所述第一信息可以为图4中的CNode B或CNode C中的信息1；所述第二信息可以为CNode A中的信息1或信息2。

更具体的，第一信息可以为图5中rslot c中存储的uslot c的标识(或称索引)，利用该标识可以查找到uslot c，进一步可以访问uslot c中存储的内容；第二信息可以为uslot c中存储的cap c的标识(或称索引)，使用该标识可以获知是cap c被授权出去了，进一步的，第二信息还可以包括rslot的标识(或称索引)，使用该标识可以获知cap c被授权给了rslot c所在的进程。应理解的是，图5这种实现方式下，删除第一信息或第二信息可以实现为删除存储存储第一信息或第二信息的容器，即slot。标识或索引的实现有很多中形式，图8给出一种具体的实现方式，但本申请不局限于此。

可见，不同于现有技术中被授权者的能力节点直接存储被授权的能力，本申请提供的这种数据结构通过存储第一信息来指示被授权的能力，即通过第一信息可以查找到被授权的能力。在被授权者放弃该能力的时候，内核可以直接删除该第一信息，避免了能力的删除，从而不会出现是否需要删除内核对象这种不确定的情况，保证了确定性时延。

另外，本申请提供的这种数据结构还存储第二信息来指示授权出去的能力，这可以使得授权者在回收某授权出去的能力的时候，可以直接删除该第二信息，而不需要复杂的算法，从而缩短了回收操作的时间。

进一步的，同一能力可以被授权给不同的被授权者，所述第二信息还用于记录被授权者是哪一个，通过这种方式，授权者可以通过指定被授权者的信息回收该被授权者的能力，提高了回收操作的精准性。

第二方面，本申请提供一种能力的管理方法，该方法可以由内核执行。该方法可以由被授权者发起。该方法可以认为是实现被授权者放弃能力授权的一种方法。具体的，该方法包括：接收被授权者发送的放弃请求，所述放弃请求中包含第一标识，所述第一标识用于指示待放弃的能力，所述待放弃的能力为授权者授权给所述被授权者的能力；从所述被授权者的能力节点中删除与所述第一标识匹配的第一目标信息，其中，所述待放弃的能力仅存储在所述授权者的能力节点中，而所述第一目标信息用于从所述授权者的能力节点中查找到所述待放弃的能力。

这里被授权者的能力节点采用的是前述方面提到的数据结构，所述第一目标信息用于指示所述待放弃的能力，但不是所述待放弃的能力本身。

在一些实现方式下删除第一目标信息可以通过删除存储信息的容器来实现，例如图5等实施例中的删除slot。

可见，被授权者需要放弃某一个被授权的能力的时候，内核可以直接删除被授权者的能力节点中与该能力对应的信息，由于没有存储该能力，所以不涉及能力的删除，从而不出现是否需要删除内核对象这种不确定的情况，保证了时延的确定性。

第三方面，本申请提供一种能力的管理方法，该方法可以由内核执行。该方法可以由授权者发起。该方法可以认为是实现授权者回收能力的一种方法。具体的，该方法包括：接收授权者发送的回收请求，所述回收请求中包含第二标识，所述第二标识用于指示待回收的能力，所述待回收的能力为所述授权者授权给被授权者的能力；从所述授权者的能力节点中删除与所述第二标识匹配的第二目标信息，其中，所述待回收的能力仅存储在所述授权者的能力节点中，所述第二目标信息用于从所述授权者的能力中查找到所述待回收的能力。所述第二目标信息用于指示所述待回收的能力已授权出去。

这里授权者的能力节点采用的是前述方面提到的数据结构，所述第二目标信息用于指示待回收的能力，但不是能力本身。

在一些实现方式下，所述第二目标信息可以独立于所述授权者的所有能力。在另一些实现方式下，所述第二目标信息可以作为能力后的一个标签或后缀等，此时删除第二目标信息可以为删除该标签或后缀。

可见，授权者回收一个能力的时候，因为该能力仅存储在该授权者的能力节点中，所以不像现有技术那样内核必须在被授权者的能力节点中执行删除能力的操作，内核只需要从授权者的能力节点中删除该能力对应的第二目标信息，从而简化了回收操作，缩短了能力回收的时长。需要说明的是，内核也可以根据实际情况在被授权者的能力节点执行删除操作，但无需像现有技术删除能力那样复杂。

在一些实现方式下，当所述授权者可以将同一个能力授权给不同的被授权者时，所述授权者的能力节点中存储的第二目标信息不仅指示已授权出去的能力，还指示该能力授权给哪个被授权者。如果所述授权者要回收某个特定被授权者(称之为目标被授权者)的能力，那么所述第二标识还用于指示该目标被授权者。这样就可以实现精准回收授权给某个被授权者的能力，不需要像现有技术那样先回收所有被授权者的能力，再重新赋予不需要回收能力的被授权者，进而缩短了回收时间。

需要说明的是，第一目标信息可以认为是多个第一信息中与请求者的要求匹配的信息，第二目标信息可以认为是多个第二信息中与请求者的要求匹配的信息，所以第一目标信息和第二目标信息的实现可参考第一方面中第一信息和第二信息的实现，具体可参考图3、图4以及图5等实现，在此不再赘述。

第四方面，本申请还提供一种能力的管理方法。该方法可以由内核执行。该方法可以由授权者发起，也可以由被授权者发起，该方法可以认为实现了能力的授权。具体的，该方法包括：接收授权者发送的授权请求，所述授权请求用于指示将所述授权者的能力节点中的目标能力授权出去，所述目标能力仅存储在所述授权者的能力节点中；在所述授权者的能力节点中记录授权信息，所述授权信息用于指示所述目标能力已授权出去；在被授权者的能力节点中记录被授权信息，所述被授权信息用于从所述授权者的能力节点中查找到所述目标能力。

被授权信息和授权信息的记录顺序不做限定。该方面中的被授权信息和授权信息分别于前述方面中的第一目标信息和第二目标信息类似，不是能力本身，可以是能力的索引或能力所在的存储结构的索引等用于标识或查找能力的信息。

采用这种授权方法，能力仅存储在能力的所有者，即授权者的能力空间中，不需要复制能力到被授权者的能力空间中，因此缩短了授权的执行时间。

在一些实现方式下，所述授权信息还可以用于指示所述目标能力授权给所述被授权者，这样当同一个能力被授权给不同的被授权者时，就会有不同的授权信息，从而，授权者回收能力的时候，就可以有针对性地删除包含某个被授权者的授权信息，实现精准回收。

在一些实现方式下，所述方法还包括：接收所述被授权者发送的放弃请求，所述放弃请求中包含第一标识，所述第一标识用于标识所述目标能力或用于标识所述被授权信息；从所述被授权者的能力节点中删除与所述被授权信息。

被授权者放弃该目标能力的时候，内核不需要删除能力，只需要删除该所述被授权信息，保证了时延的确定性。

在一些实现方式下，所述方法还包括：接收所述授权者发送的回收请求，所述回收请求中包含第二标识，所述第二标识用于标识所述目标能力或用于标识所述授权信息；从所述授权者的能力节点中删除所述授权信息。

授权者回收能力的时候，由于被授权者的能力节点中不存储能力，所以内核不需要执行删除能力的操作，只需要将所述授权信息删除，即解除该能力与被授权者的关系，从而缩短回收的时长。

前述方面提供的方法是从内核角度说明，下面从用户态来说明。下面方面中涉及的内核实现部分可参考前述方面。

第五方面，本申请提供一种能力管理方法，包括：授权者向内核发送授权请求(例如调用接口Grant，即发送授权请求)，所述授权请求中包括授权参数(例如cref)，所述第一参数用于指示待授权的能力；所述授权请求用于指示所述内核将所述待授权的能力授权给被授权者；获得所述内核返回的的回收参数(例如uref)，所述回收参数用于所述授权者管理(例如回收)本次授权。

在一些实现方式中，所述方法还包括：所述授权者向所述内核发送回收请求(例如调用接口Revoke，即发送回收请求)，所述回收请求中包括所述回收参数(例如uref)，所述回收参数被所述内核用于执行能力回收。

在一些实现方式中，所述方法还包括：所述被授权者向所述内核发送准备请求(例如调用接口PrepareGrant，即发送准备接收授权请求)；获得所述内核返回的放弃参数(例如rref)，所述放弃参数用于所述被授权者管理(例如放弃)被授权的所述能力。

在一些实现方式中，所述方法还包括：所述被授权者向所述内核发送放弃请求(例如调用接口Reject,即发送放弃请求)，所述放弃请求中包含所述放弃参数(例如rref)，所述放弃参数被所述内核用于执行能力放弃。

除了数据结构及方法之外，本申请还实现方法的装置、计算机存储介质和计算机程序产品、应用程序接口(application program interface,API)等。

第六方面，本申请提供一种计算机设备，所述计算机设备包括硬件层以及运行在所述硬件层上的操作系统，所述操作系统包括内核，所述内核用于执行如前述任一方面的任意一项提供的方法。授权者和被授权者可以为操作系统内的进程或应用的进程。该内核可以为微内核，也可以为宏内核。该计算机设备可以为终端设备，例如智能手机等，该计算机设备还可以为应用于无人驾驶的智能设备，或者虚拟现实/增强现实/混合现实设备、人工智能设备等。

第七方面，本申请提供一种能力的管理装置，所述装置包括一个或多个模块，用于实现前述任一方面的任意一项提供的方法。在一些实现方式中，该装置可以为操作系统，或操作系统的内核。该内核可以为微内核，也可以为宏内核。在一些实现方式中，该装置可以为用户态的应用。

第八方面，本申请提供一种计算机设备，所述计算机设备包括一个或多个处理器和存储器，所述存储器用于存储计算机可读指令，所述一个或多个处理器用于读取所述计算机可读指令实现前述任一方面的任意一项提供的方法。该计算机设备可以为终端设备，例如智能手机等，该计算机设备还可以为应用于无人驾驶的智能设备，或者虚拟现实/增强现实/混合现实设备、人工智能设备等。

第九方面，本申请提供一种计算机存储介质，所述计算机存储介质用于存储计算机程序，当所述计算机程序被一个或多个处理器执行时实现前述任一方面的任意一项提供的方法。

第十方面，本申请提供一种计算机程序产品，所述计算机程序产品用于存储计算机程序，当所述计算机程序被一个或多个处理器执行时实现前述任一方面的任意一项提供的方法。

在一些实现方式中，所述计算机程序产品为操作系统或操作系统的内核。在另一些实现方式中，所述计算机程序产品为应用。

第十一方面，本申请还提供一个或多个API。这些API可以以系统调用的形式由内核向用户态提供，供用户态进程调用，以实现本申请提供的任意一种或多种能力管理方法。

本申请提供的方案可以应用于微内核架构，也可以应用于宏内核架构。本申请提供的能力管理方法能够实现内核对象的访问权限授权和回收，同时能够保证确定性时延。

附图说明

下面将对本申请附图作简单地介绍。显而易见地，下面描述的附图仅仅是本申请的一些实施例。

图1为现有技术中能力拷贝的过程示意图；

图2为本申请提供的一种能力节点的示意图；

图3为本申请提供的另一种能力节点的示意图；

图4为能力授权场景下本申请提供多个能力节点的示意图；

图5为本申请提供的一种更具体的能力节点的示意图；

图6为能力授权过程的示意图；

图7A为授权者回收能力的过程示意图；

图7B为被授权者放弃能力的过程示意图；

图8为本申请提供的一种更具体的能力节点的示意图；

图9为本申请提供的一种能力管理装置的逻辑结构示意图；

图10为本申请提供的一种计算机设备的逻辑结构示意图。

具体实施方式

为方便理解本申请的实施例，下面首先对本申请中出现的技术概念做介绍。应理解的是，这些技术概念应用在本申请下文将要介绍的实施例中，但这些实施例仅是本发明提供的方案的部分实施例中，所以这些技术概念并非一定要应用在本申请所有实施例中。

宏内核：一种操作系统内核架构，此架构的特点是整个内核程序都运行在内核空间(kernel space)。相对于其他类型的操作系统架构，如微内核架构或混合内核架构等，宏内核独自提供了计算机硬件的统一高层虚拟接口。它提供了一系列的系统调用来实现各种操作系统服务，比如进程管理、程序并发、内存管理、各种驱动程序等。

微内核：另一种操作系统内核架构，此架构的特点是将尽可能少的功能运行在内核空间(kernel space)，并提供必要的机制来实现操作系统。这些机制包括地址空间管理、线程管理、进程间通信等。相比于宏内核，微内核将众多的组件，比如文件系统和网络协议栈等都放在用户态运行，而将自己真正的内核功能减少到非常少。

进程：程序的运行实体。程序是指令、数据及其组织形式的描述，进程是程序的运行实体。一个进程中可以并发多个线程，每条线程并行执行不同的任务。线程可以是进程的实际运作单位，但本申请实施例不对线程和进程进行明确区分，描述过程中都用进程代替。

用户态进程：运行在用户态，而非内核空间的进程。不论是用户态进程，还是内核，它们实现的功能都是软件代码实现的，所以它们执行的方法也可以认为是处理器读取软件代码后执行的方法。

确定性时延：时延是指业务的执行时间，确定性时延是指业务的执行时间的波动需保证在有限范围内。比如对于无人驾驶或辅助驾驶系统，前面有障碍物需要识别，识别障碍物的时间要控制在波动范围，否则，感知业务就没办法做规划，感知之后的控制业务就没办法在确定的时间内给出机械反应，比如，刹车。整个系统的确定性时延，由系统各组件共同来决定。操作系统的确定性时延是整个系统确定性时延的根基，这要求，内核要在确定的时间范围内给用户态进程响应。

能力的派生关系：进程A若需要与进程B共享内核对象O，则将自己的能力节点中该内核对象的能力C拷贝到进程B的能力节点中，作为能力C1。这样，进程B就可以访问该内核对象O了。能力C1则是派生自能力C。进程B还可以继续执行共享，即进程B还可以将能力C1拷贝到进程C的能力节点中，作为能力C2。能力C2直接派生自能力C1，间接派生自能力C。C、C1和C2的这种关系就是能力的派生关系。

进程间通信(Inter process communication)：是操作系统提供的一种允许进程之间相互传递消息的通信机制。

现有技术中的能力授权是通过能力的拷贝(或称派生)实现的。能力拷贝通过进程间通信完成。待授权的能力被存储在授权者的发送缓存(buffer)中。该发送缓存中还可以存储能力的数量,一次可以授权多个能力。被授权者通过接收消息来接收能力，并且提供存储能力的空间。

具体的，图1为能力拷贝的过程示例。假设进程A要把能力cap 1授权给进程B。cap1记录了对内核对象O的访问权限。cap 1存储在进程A的能力节点CNode A的一个槽(slot)中。

第1步：进程A向进程B发送消息，该消息中包cap1的索引(或称标识)。该授权操作由进程A发起，通过调用系统调用发送消息，并在消息中指定能力的索引。消息的传输由内核完成。

第2步：进程B在自己的CNode B中申请一个新的存储单元，并得到该存储单元的索引。该操作由进程B发起，调用系统调用进入内核，由内核在CNode B中分配一个存储单元槽(slot)。slot是现有的微内核操作系统中常用的存储能力的存储单元。

第3步：进程B接收到消息，并指定前一步骤中分配的slot作为能力的存储单元。该操作由进程B发起，调用系统调用接收信息，并指定存储能力的slot。

第4步：内核把cap 1的内容拷贝到slot中，成为cap 11。由于cap 11中包括内核对象O索引，所以步骤4之后根据slot可以索引到内核对象O。

第5步：内核记录cap 1和cap 11的派生关系。记录派生关系的方式有多种，比如记录cap 1的索引和cap 11的索引的对应关系，或记录存储cap 1的slot和存储cap 11的slot的对应关系等。

以上仅是示例，在具体实现中步骤的顺序可以发生变化，例如第1步和第2步的顺序可以交换、或授权的最初请求者可以为被授权者等，本申请不再一一列举。

现有技术的涉及能力删除的情况包括至少两种。第一种情况是授权者回收能力。具体的，授权者向内核发起回收能力的请求，并指定待回收的能力的索引；内核根据能力的派生关系，删除所有派生自该能力的能力，包括直接派生和间接派生的能力。第二种情况是被授权者放弃授权。具体的，被授权者向内核发起删除能力的请求，并通过指定slot的索引来指定待删除的能力，该slot就是存储该待删除的能力的slot；内核从被授权者的CNode中删除能力。

采用现有技术提供的能力机制，虽然能够实现能力的授权和回收，但是却不能保证确定性的时延。具体的，由于能力授权过程中存在拷贝，所以可能存在多个能力指向同一个内核对象的情况，所以当被授权者主动放弃一个能力的授权时，可能有两种情况：1.当该能力不是指向它包含的内核对象的最后一个能力时，只需把该能力从能力节点中即可；2.当该能力是指向该内核对象的最后一个能力时，不仅要把该能力删除，同时还要把该内核对象删除，否则，会导致内存泄漏，因为没有别的方式能访问到该内核对象了。由于以上不同情况下的耗时是不同的，这为确定性时延的分析带来了很大挑战。在分析一个程序的时延时，对于删除能力的行为，由于不确定这是否是引用内核对象的最后一个能力，只能按照最坏的情况来分析，即按照会触发内核对象回收的情况来计算时延，这样会导致时延分析的结果总是最差的情况，但这与实际的运行结果并非总是一致。因此，这种时延分析是不准确的，换句话说，主动放弃能力的时延是无法确定的，这就导致整个程序的时延很难确定。

针对上述问题，本申请提供一种能力管理方法，该方法提出能力所有者(owner)的概念。能力所有者通过在自己的存储空间中存储授权信息实现对能力的集中管理,从而实现能力回收的确定性时延。这里的授权信息包括授权出去的能力的信息和获得授权的能力的信息。

图2为本实施例提供的一个能力所有者的存储空间的逻辑结构示意图。该能力所有者为一个进程，该进程的用于存储授权信息的存储空间为能力节点。如图2所示，该能力节点中包括三种信息：“能力”、“授权出去的能力信息M2”以及“被授权的能力信息M1”。举例来说，一个能力被授权出去，则该能力被记录在“授权出去的能力信息”中，如果一个能力被从其他进程授权过来，那该能力被记录在“被授权的能力信息”中。

能力节点中记录的“授权出去的能力信息M2”和“被授权的能力信息M1”都不是能力本身，是指示这两种授权关系的授权信息。使用该信息可以索引到对应的能力。具体的，“被授权出去的能力”是用于指示该能力被授权出去的信息。比如可以通过为某个能力加入标识的方式指示某个能力已经授权出去，或如下面实施例所述，通过一个额外的数据结构存储授权出去的能力的标识。类似的，“被授权的能力信息M1”是用于索引到被授权(过来)的能力的信息，使用该信息可以找到授权者的能力节点中存储的能力。

应理解的是，在具体的操作系统中，并非所有进程的能力节点中都必须包含以上三种信息，某些进程的能力节点中可能不存在授权出去的能力和/或被授权的能力。

在本申请中，一个进程就是其能力节点中包括的“能力”的所有者(owner)。按照现有技术，一个“能力”一旦被授权出去，就会被拷贝到其他进程的能力节点中，但是本申请提供的方法不需要能力拷贝，只需要通过“授权出去的能力信息”和“被授权的能力信息”记录下授权关系即可。所以一个能力不管有没有授权，都只有一份，只有一个“所有者”。

有多种方式来确定一个能力的所有者，比如由内核把能力赋予一个进程，即在该进程的CNode中创建能力；或者当一个进程创建一个内核对象时，该内核对象对应的能力也被同时创建，则这个进程就是该能力的“所有者”。本申请对能力所有者的确定方式不限定。另外，能力的所有者允许改变，比如一个能力的所有者可以从进程A变成进程B，这不影响本申请提供的方法。

需要说明的是，在本实施例中，一个内核对象只有一个能力与之相对应，内核对象与能力一一对应。每个能力都有一个所有者，并存放在所有者的能力节点中。但在其他实施例中，整个操作系统中不排除有部分内核对象存在多个能力，并将这些能力分别存储在多个能力节点中的情况，具体需不需要这种设计，依据实际的需求，本申请对此不做限定。

图3为存储空间的另一实施例。如图所示，能力中存储多个能力，其中有些能力可以通过添加额外信息(M2)的方式标识其已经授权。具体的，该额外信息可以包括该能力授权给谁、以及授权的权限。未添加该额外信息的能力可以认为没有授权出去，当然也可以添加另一额外信息标识该能力没有授权出去。

图4为授权者授权能力给被授权者的一个示例，图4显示了进程A将自己存储的能力c分别授权给了进程B和进程C。如图所示，CNode A中存储了两个信息，信息1指示能力c授权给进程B；信息2表明能力c授权给进程C。CNode B中存储了信息1，该信息1表明获得了进程A的能力c的授权。CNode C中存储了信息1，该信息1表明获得了进程A的能力c的授权。若进程B或进程C放弃能力c的授权，则内核可以删除CNode B或CNode C中的信息1。若进程A回收授权给进程B的能力c，则内核可以删除CNode A中的信息1；若进程A回收授权给进程C的能力c，则内核可以删除CNode A中的信息2。

图2至图4介绍了本申请提供的能力节点的数据结构以及可能存储的信息，数据结构或数据结构中存储的信息的具体实现有很多种，下面实施例以微内核系统中常用的数据结构为例来介绍本申请提供的方案的具体实现。应理解的是，下面的具体实现仅是示例，本领域技术人员容易在这些实现的基础上对数据结构或信息形态做出改变，也能实现本申请提供的方案。

图5为本申请实施例提供的能力节点的一个更具体的逻辑结构示意图。CNode A为进程A的能力节点，CNode B为进程B的能力节点。两个能力节点中分别包含三个数据结构：能力表(capability table，简称为ctable)、认证表(authorization table，简称为utable)以及引用表(reference table，简称为rtable)。

需要说明的是，这里用“表”仅是作为三个数据结构的命名，但实际实现时该数据结构可以实现为多种形式，并不限制为表。

ctable用于记录一个进程所拥有的能力。每个能力被存放在一个slot中，本申请称之为cslot。能力只能被内核直接访问。每个能力有一个唯一的引用，称作cref。用户态进程可以通过cref来指定要访问的能力。比如，进程A发起授权时，使用cref来指定要授权的能力。应理解的是，为了方便描绘，图中仅示出了一个cslot，实际实现中可以有多个，类似的，uslot和rslot也可以有多个。

需要说明的是，在其他实施例中，多个能力也可以被存放在一个slot中，只要能区分能力即可。

utable记录能力授权信息，或称授权出去的能力的信息。能力授权信息被存放在uslot中。能力授权信息记录了被授权的能力、授权的权限以及该能力授权给谁。记录被授权的能力的方式有多种：比如直接记录能力的引用cref，或者记录能力所在的cslot的索引。每个uslot有一个唯一的引用，称作uref。用户态进程通过uref来指定其要访问的uslot。比如，授权者回收授权时，可以使用uref来指定要回收的能力。

rtable记录被授权信息。被授权信息被存放在rslot中。rslot中记录了被授权的能力信息。每个rslot有一个唯一的引用，称作rref。用户态进程通过rref来指定其要访问的rslot。比如，放弃授权时，用户态进程可以使用rref来指定要放弃的能力。访问对应的内核对象，也是通过rref来指定。rslot还可以有一个索引，该索引用于标识该rslot在rtable中的位置。

需要说明的，本实施例中uslot和rslot中存放的不是能力，但是可以根据其存放的信息，找到与之对应的能力。图中仅使出了CNodeB中的rtable，可以理解的是，CNode A中若存在rtable，也是类似的实现。

因为uslot和rslot分别记录了授权出去的能力和被授权的能力的信息，所以在如图3的示例中，CNode A的uslot和CNode B的rslot具有对应关系，即根据uslot可以找到对应的rslot，根据rslot可以找到对应的uslot。

进一步的，一个能力可能被授权多次，就可以有多个uslot与之对应，使用uref来指定具体回收哪次授权。如图3所示，CNode B中示例性的描绘了两个uslot:uslot b1和uslot b2。uslot b1记录进程B授权给进程C一个能力，uslot b2记录进程B将该能力授权给进程D，授权的权限可以相同也可以不同。这样就用两个uslot分别记录了一个能力的两次授权。当进程B需要回收授权给进程D的能力的时候，可以通过uslot b2的引用uref来删除uslot b2。

当授权者回收能力时，现有技术会使用能力的索引，例如cref，来指定需要回收的能力，这样会一下子回收一个能力的所有授权。但是，本实施例提供的方法，由于同一个能力的不同授权对应不同的uslot，所以可以通过uslot的引用来指定需要回收的授权，这样就能够实现细粒度的、更加精准的授权回收。

应理解的是，如果系统不需要这种精准的回收，或者系统设定了一个能力只能授权一次，那么本申请的提供的方法也可以通过能力的引用cref，来指定需要回收的能力。

图6为基于图5的能力授权过程的示例。假设待授权出去的能力为进程A的能力capc，cap c存储在ctable的一个cslot c中，cap c对应的内核对象为内核对象o。如图所示，能力授权过程包括：

第1步：进程B调用系统调用以发起请求授权操作。具体的，在进程B调用系统调用之后，内核在CNode B的rtable中分配一个项rslot c，并把该rslot c的引用rref返回给进程B。这里rslot c表示与cap c对应的rslot。

第2步：进程A调用系统调用以发起授权操作。具体的，在进程A调用系统调用之后，内核在CNode A的utable中分配一个项，uslot c。这里uslot c表示与cap c对应的uslot。

第3步：内核在uslot c中记录cap c的索引。这一步的目的是建立uslot c和cap c的关系，记录下授权出去的能力是cap c。

第4步：内核在rslot c中记录uslot c的索引，在uslot c中进一步记录rslot c的索引。内核把uslot的引用uref返回给进程A。这一步的目的是建立uslot c和rslot c的联系，记录下cap c被授权到rslot c中，同时rslot c的授权来源于uslot c。

应理解的是，在操作系统中，用户态进程通过系统调用进入内核态，之后内核执行程序，执行完成之后再返回用户态进程。

执行完上述能力授权过程之后，进程B就可以根据rref访问rslot c，之后，根据rslot c中记录的信息访问uslot c，然后根据uslot c中记录的信息访问cap c。

在完成上述授权之后，进程B访问内核对象o的过程如下：进程B用rslot c的rref来指定它要访问内核对象o。内核根据rref，从进程B的CNode B中找到对应的rslot c，然后根据rslot c找到对应的uslot c(进程A的CNode A中)。在uslot c中记录了对内核对象o的访问权限(这里记录的是授权给进程B的权限)。如果进程B请求的操作不被uslot c中的权限所允许，那么这个访问会被拒绝，否则，允许访问。还有一种可能，uslot c中没有记录内核对象的访问权限，那么内核可以根据uslot c中记录的cap c的索引找到cap c，根据capc中记录的权限来确定是否可以执行该访问。

需要说明的是，在uslot c和rslot c中记录的信息只需要能保证记录下授权出去的能力或被授权的能力之间的关系即可，即保证被授权者能找到对应的能力，并不限定于仅记录彼此的索引，可以还包含其他的信息或记录其他信息(例如直接记录彼此的引用)。

进一步的，图7为基于图5的能力回收过程的示例。图7(A)为进程A回收能力授权的过程。图7(B)为进程B放弃能力授权的过程。

如图7(A)所示，进程A删除uslot c即可回收授权给进程B的cap c。

需说明的是，本实施例中并不需要删除rslot c。删除掉uslot c就已经解除了授权，因为进程B已经无法使用uslot c的uref访问到对应的能力了。在其他实施例中，可以考虑删掉rslot c，但不作为强制要求。

如图7(B)所示，进程B删除rslot c即可放弃cap c的授权。类似地，不需要同时删除uslot c。

需要说明的是，slot类似一个存储容器，删除uslot c或删除rslot c意味着将其中保存的数据和这个结构(这个结构本身也是数据)都删除。在其他一些实施例中，也可以仅删除容器中存储的数据，而保留容器。

可见，通过本实施例提供的方法，在被授权者放弃授权的过程中，授权者只需要删除对应的rslot，不需要删除能力，也不涉及内存对象的删除，所以这个时延是可以确定的。而且，仅删除rslot，相比现有技术删除能力以及判断能力是否是最后一个能力等操作，所需要的时间也更少。

另外，由于能力只被所有者持有，所以所有者可以随时删除该能力对应的内核对象或该能力，使得对内核对象的管控更加集中和有效。能力的所有者删除能力的时候，必须删除内核对象，这个时延也是可以确定。

进一步的，所有者可以记录同一个能力授权给不同的进程的不同授权信息，这样在回收能力的时候，可以对某一次授权做精准的回收。现有技术对待这种情况要先回收所有授权，再把不需要回收的授权再次授予，相比现有技术，本实施例提供的回收方法更加精准，用时也更少。

现有技术中，授权者回收能力时，由于可能存在级联授权，比如进程A把它的能力拷贝给进程B，进程B又把该能力拷贝给进程C，在进程A回收授权的时候，需要进程C相应的能力也回收。导致授权者回收授权时，需要回收的权限数量是不确定的。为了实现确定性时延，整个回收算法会十分复杂。而采用本申请提供的方法，授权者回收授权的时候只需要删除授权关系记录，不会触发级联回收，也不会触发内核对象的删除，所以不需要负责的回收算法，回收速度比现有技术要快。

下面通过在微内核中实现的一个更具体的实施例介绍本申请提供的能力管理方法。如图8所示，在微内核系统中，基于三张表实现能力机制。在CNode中，使用数据结构映射(map)来实现ctable、utable和rtable，三张表中的每个元素有一个索引与之相对应。在其他实施例中，也可以使用其它数据结构，例如集合(set)或数组(array)等实现这三张表。

ctable：由一个map实现，索引为正整数，值为capability。每个capability存放两部分信息：a)内核对象的引用；b)访问内核对象的权限。capability的引用cref用一个64位整数表示，前32位为其所有者CNode的索引，后32位为capability在其所有者CNode ctable中的索引。CNode的索引是CNode在CSpace中的编号。

如图8，CNode A的索引为0x01，cap c在CNode A的ctable中的索引为0x03，cap c的cref为0x0000000100000003。

utable：由一个map实现，索引为正整数，值为utable_node。每个utable_node存放四部分信息：a)被授权的capability在ctable中索引；b)授权的权限；c)被授权者的CNode的索引；d)被授权者CNode中的rtable_node在rtable中的索引。utable_node的引用uref用一个64位整数表示，前32位为CNode的索引，后32位为utable_node在utable中的索引。

如图8，CNode A的索引为0x01,utable_node c在utable中的索引为0x04，所以utable_node c对应的uref为0x0000000100000004。

rtable：由一个map实现，索引为正整数，值为rtable_node。每个rtable_node存放两部分信息：a)授权者的CNode的索引；b)授权者CNode中的utable_node在utable中的索引。rtable_node的引用rref用一个64位整数表示，前32位为CNode的索引，后32位为rtable_node在rtable中的索引。

如图8，CNode B的索引为0x02,rtable_node c在rtable中的索引为0x05，故rtable_node c的引用rref为0x0000000200000005。

本实施例为了实现cap c的授权，具体实施步骤如下:

第1步：内核在CNode B的rtable中分配一个rtable_node c。之后，进程B得到该rtable_node c的引用rref。

第2步：内核在CNode A的utable中分配一个utable_node c。之后，进程A得到该utable_node c的引用uref。

第3步：内核在utable_node c中记录cap c在ctable中的索引，以及授权出去的权限。可选的，若授权的过程中不修改权限，也可以不记录授权出去的权限。

第4步：内核在rtable_node c中记录a)utable_node c在CNode A中utable的索引；b)CNode A的索引。进一步的，内核在utable_node c中记录a)rtable_node c在CNode B中rtable的索引；b)CNode B索引。

需要说明的是，utable_node c在CNode A中utable的索引和CNode A的索引组合起来可以认为是utable_node c的引用uref；类似的，rtable_node c在CNode B中rtable的索引和CNode B索引组合起来可以认为是rtable_node c的引用rref。本实施例中将组成引用的信息分开存储，也能达到目的。在实际的实现中，uref和rref中可能还包含其他的信息，例如标识信息，用于标识自己是哪一种引用。

执行完cap c上述授权流程之后，utable_node c中存储的信息包括：a)能力cap c的索引0x03；b)授权的权限，假设为只读；c)CNode B的索引0x02；d)rtable_node c在rtable中的索引0x05。rtable_node c中存储的信息包括：a)CNode A的索引0x01；b)utable_node c在utable中的索引0x04。

容易理解的是，前述实现也有一些变形实现，比如rtable_node c中可以记录utable_node c的uref，这样就即包含了CNode A的索引，又包含了utable_node c在CNodeA中utable的索引。

需要说明的是，本实施中的utable_node是前述实施例中uslot的一种具体实现；rtable_node是前述实施例中rslot的一种具体实现。

进程A若想回收授权，则调用系统调用以删除uref对应的utable_node c。进程B若想放弃授权，则调用系统调用以删除rref对应的rtable_node c。

本实施例还可以提供新的应用程序接口(Application Program Interface,API)(即前述系统调用)，以便于用户态进程实现前述能力授权和能力回收过程：

接口PrepareGrant：用于被授权者准备接收授权。具体的，调用者得到一个rref，并在完成之后使用该rref访问接收到的capability。例如，进程B可以在前述步骤1中调用该接口。

接口Grant：授权者开始授权。具体的，调用者用cref指定被授权的capability，并得到一个uref。调用者之后使用uref管理这次授权，比如回收授权。例如，进程A可以在前述步骤2中调用该接口。

接口Revoke：授权者回收授权。具体的，调用者使用uref来指定要回收的授权。例如，进程A可以在前述回收授权时调用该接口。

接口Reject：被授权者放弃授权。具体的，调用者使用rref来指定要放弃的授权。例如，进程B可以在前述放弃授权时调用该接口

需要说明的是，接口的名称PrepareGrant、Grant、Revoke以及Reject只是举例，本申请并不以此为限。

为简化申请文件，该实施例的过程简化描述，更多实现，例如授权发起等，可参考前述实施例。

可见，在现有技术方案中，被授权者放弃授权，是通过删除能力的方式，而由于存在能力的拷贝，所以一个内核对象可能存在多个能力指向它，导致删除能力的时延不确定。在本实施例中，通过储存能力的授权关系，而不是通过能力的拷贝来完成授权。被授权者放弃授权时通过删除授权关系的记录来实现，能够实现确定性时延。

进一步的，利用本申请提供的方法，每个内核对象只有一个能力指向它，在删除一个能力时，同时删除其指向的内核对象。换句话说，只有在需要删除内核对象时，才需要删除能力。

进一步的，所有的能力由其拥有者所持有，它可以通过修改授权关系记录来对单独的某次授权进行管理，实现了更精准、更快、更细粒度的能力管理。

综合而言，本申请提供的方法在保证确定性时延的同时，也能有效支持内核对象的主动共享和回收，实现进程资源的隔离，保持了权限管理的灵活性，并提高了能力授权和能力回收等操作的效率。

请参考图9，为本申请提供的能力管理装置的逻辑结构示意图。如图所述，该能力管理装置100位于整个计算机系统的内核中，用户态进程A、用户态进程B等进程可以通过系统调用使用能力管理装置100提供的方法。内核中存储有用户态进程A的能力节点A，以及用户态进程B的能力节点B，所有的能力节点存储在能力空间中。在本实施例中以进程A为授权者，进程B为被授权者为例介绍。

能力管理装置100包括授权模块101、放弃模块102以及回收模块103，分别用于实现能力的授权、能力的放弃以及能力的回收。

授权模块101用于接收进程A发送的授权请求，所述授权请求用于指示将能力节点A中的目标能力授权出去，所述目标能力仅存储在所述能力节点A中；在所述能力节点A中记录授权信息，所述授权信息用于指示所述目标能力已授权出去；在能力节点B中记录被授权信息,所述被授权信息用于从所述能力节点A中查找到所述目标能力。

放弃模块102用于接收所述进程B发送的放弃请求，所述放弃请求中包含第一标识，所述第一标识用于指示待放弃的能力，所述待放弃的能力为所述进程A授权给所述进程B的能力；从能力节点B中删除与所述第一标识匹配的第一目标信息，其中，所述待放弃的能力仅存储在所述能力节点A中，而所述第一目标信息用于从能力节点A中查找到所述待放弃的能力。

回收模块103用于接收进程A发送的回收请求，所述回收请求中包含第二标识，所述第二标识用于指示待回收的能力，所述待回收的能力为所述进程A授权给进程B的能力；从所述能力节点A中删除与所述第二标识匹配的第二目标信息，其中，所述待回收的能力仅存储在所述能力节点A中，所述第二目标信息用于从所述能力节点A中查找到所述待回收的能力，或者说所述第二目标信息用于指示所述待回收的能力已授权出去。

可选的，当所述进程A将同一个能力授权给不同的进程时，所述第二标识还用于指示目标进程，所述目标进程为所述不同的进程中的一个，所述第二目标信息还用于指示所述目标被授权者，例如目标进程的标识、或者目标进程的能力节点的标识或如前述实施例中slot的索引等。第二目标信息只要能够指示出能力授权给谁即可。

本实施例提供的能力管理装置100的效果可以参考前述方法实施例，在此不再赘述。

请参考图10，为本实施例提供的一种计算机系统的结构示意图。该计算机系统可以为智能手机、智能家居设备(例如大屏电视、智能电视、智能语音设备等)、辅助自动驾驶设备、或无人驾驶设备等。如图所示，该计算机系统包括通信模块510、传感器520、用户输入模块530、输出模块540、处理器550、音视频输入模块560、存储器570以及电源580。

通信模块510可以包括至少一个能使该计算机系统与通信系统或其他计算机系统之间进行通信的模块。例如，通信模块510可以包括有线网络接口、广播接收模块、移动通信模块、无线因特网模块、局域通信模块和位置(或定位)信息模块等其中的一个或多个。这多种模块均在现有技术中有多种实现，本实施例不再一一描述。

传感器520可以感测系统的当前状态，诸如打开/闭合状态、位置、与用户是否有接触、方向、和加速/减速，并且传感器520可以生成用于控制系统的操作的感测信号。

用户输入模块530，用于接收输入的数字信息、字符信息或接触式触摸操作/非接触式手势，以及接收与系统的用户设置以及功能控制有关的信号输入等。用户输入模块530包括触控面板和/或其他输入设备。

输出模块540包括显示面板，用于显示由用户输入的信息、提供给用户的信息或系统的各种菜单界面等。可选的，可以采用液晶显示器(liquid crystal display，LCD)或有机发光二极管(organic light-emitting diode,OLED)等形式来配置显示面板。在其他一些实施例中，触控面板可覆盖显示面板上，形成触摸显示屏。另外，输出模块540还可以包括音频输出模块、告警器以及触觉模块等。

音视频输入模块560，用于输入音频信号或视频信号。音视频输入模块560可以包括摄像头和麦克风。

电源580可以在处理器550的控制下接收外部电力和内部电力，并且提供系统的各个组件的操作所需的电力。

处理器550可以指示一个或多个处理器，例如，处理器550可以包括一个或多个中央处理器，或者包括一个中央处理器和一个图形处理器，或者包括一个应用处理器和一个协处理器(例如微控制单元或神经网络处理器)。当处理器550包括多个处理器时，这多个处理器可以集成在同一块芯片上，也可以各自为独立的芯片。一个处理器可以包括一个或多个物理核，其中物理核为最小的处理单元。

存储器570存储计算机程序，该计算机程序包括操作系统程序572和应用程序571等。典型的操作系统如seL4、L4、或谷歌公司提供的Fuchsia等微内核操作系统；又如微软公司的Windows，苹果公司的MacOS等用于台式机或笔记本的系统；又如谷歌公司开发的基于

的安卓

系统等用于移动终端的系统等。

存储器570可以是以下类型中的一种或多种：闪速(flash)存储器、硬盘类型存储器、微型多媒体卡型存储器、卡式存储器(例如SD或XD存储器)、随机存取存储器(randomaccess memory,RAM)、静态随机存取存储器(static RAM,SRAM)、只读存储器(read onlymemory,ROM)、电可擦除可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、可编程只读存储器(programmable ROM,PROM)、磁存储器、磁盘或光盘。在其他一些实施例中，存储器570也可以是因特网上的网络存储设备，系统可以对在因特网上的存储器570执行更新或读取等操作。

处理器550用于读取存储器570中的计算机程序，然后执行计算机程序定义的方法，例如处理器550读取操作系统程序572从而在该系统运行操作系统以及实现操作系统的各种功能，或读取一种或多种应用程序571，从而在该系统上运行应用。本申请提供的方案如果用软件形式实现，就可以以计算机程序的方式存储在存储器570中，具体的，以操作系统程序572的全部或部分存在，并由处理器550读取并执行。

存储器570还存储有除计算机程序之外的其他数据573，例如本申请中涉及的各种能力节点等。

图10中各个模块的连接关系仅为一种示例，本申请任意实施例提供的方法也可以应用在其它连接方式的终端设备中，例如所有模块通过总线连接。图10中各个模块的划分仅是逻辑上的划分，并不代表硬件上一定是分开的。图10中各个模块在本申请的其他实施例中未必是必要的。

另外，本申请还提供与本申请提供的方案相关的存储介质、计算机程序产品、计算机程序等。具体实现可参考前述实施例。

为完整描述本申请的方案，本申请将实现方式分开多个部分介绍，为了更好地让读者理解本申请的方案，本申请也提供了不同的案例来说明整个方案。应理解的是，各个部分之间存在一些关联，相互关联的实现可相互参考。案例与各个部分的实现之间存在一些重复，也可以相互参考，但这并不意味着某种案例一定要按照某种过程来实现。

需要说明的是，capability、CNode、CSpace、以及slot等是现有的微内核操作系统中常用的概念，为方便本领域技术人员理解，本发明实施例以此为例，但可以理解的是，概念的名称若发生变化，本申请亦可以适用。

需要说明的是，为了方便应用和理解，本申请实施例为提到的一些系统、模块、器件、元素、数据结构以及指令等进行了命名，这些命名的大写或小写在无特殊说明的情况下均是相同的含义。同时，这些命名可以根据需求变更，不应作为对本申请所提供方案的限定。

需要说明的是，本实施例提供的方案可以应用于终端设备或服务器等。这里的终端设备包括但不限于智能手机、车载装置(例如自动驾驶设备)、个人计算机、人工智能设备、平板电脑、个人数字助理、智能穿戴式设备(例如智能手表或手环、智能眼镜)、智能语音设备(例如智能音箱等)、虚拟现实/混合现实/增强显示设备或网络接入设备(例如网关等)等。服务器可以包括存储服务器或计算服务器等。

需要说明的是，前述实施例中提出模块或单元的划分仅作为一种示例性的示出，所描述的各个模块的功能仅是举例说明，本申请并不以此为限。本领域普通技术人员可以根据需求合并其中两个或更多模块的功能，或者将一个模块的功能拆分从而获得更多更细粒度的模块，以及其他变形方式。

以上描述的各个实施例之间相同或相似的部分可相互参考。本申请中的“多个”若无特殊说明，指两个或两个以上，或“至少两个”。本申请中的“A/B”包括三种情况：“A”、“B”和“A和B”。本申请中一个对象的“标识(id)”指的是唯一标识该对象的信息，该“标识”可以直接标识该对象，例如对象的名称，也可以间接指示该对象，例如对象的存储地址。本申请中“第一”、“第二”、“第三”等仅为了区分表述，没有限定顺序的意思；再者，由于没有限定顺序，所以没有第一，也可以有第二或第三。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述，仅为本申请的一些具体实施方式，但本申请的保护范围并不局限于此。

Claims (14)

1.一种能力的管理方法，其特征在于，包括：

接收被授权者发送的放弃请求，所述放弃请求中包含第一标识，所述第一标识用于指示待放弃的能力，所述待放弃的能力为授权者授权给所述被授权者的能力；

从所述被授权者的能力节点中删除与所述第一标识匹配的第一目标信息，其中，所述待放弃的能力仅存储在所述授权者的能力节点中，而所述第一目标信息用于从所述授权者的能力节点中查找到所述待放弃的能力。

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

接收授权者发送的回收请求，所述回收请求中包含第二标识，所述第二标识用于指示待回收的能力，所述待回收的能力为所述授权者授权给被授权者的能力；

从所述授权者的能力节点中删除与所述第二标识匹配的第二目标信息，其中，所述待回收的能力仅存储在所述授权者的能力节点中，所述第二目标信息用于从所述授权者的所有能力中查找到所述待回收的能力。

3.根据权利要求2所述的方法，其特征在于，所述第二标识还用于指示目标被授权者，所述目标被授权者为不同的被授权者中的一个；

所述从所述授权者的能力节点中删除与所述第二标识匹配的第二目标信息，包括：

从所述授权者的能力节点中删除与所述第二标识匹配的第二目标信息，所述第二目标信息还用于指示所述目标被授权者。

4.根据权利要求1-3任意一项所述的方法，其特征在于，还包括：

接收授权者发送的授权请求，所述授权请求用于指示将所述授权者的能力节点中的目标能力授权出去，所述目标能力仅存储在所述授权者的能力节点中；

在所述授权者的能力节点中记录授权信息，所述授权信息用于指示所述目标能力已授权出去；

在被授权者的能力节点中记录被授权信息,所述被授权信息用于从所述授权者的能力节点中查找到所述目标能力。

5.一种计算机设备，其特征在于，所述计算机设备包括存储器和处理器，所述存储器用于存储计算机可读指令，所述处理器用于读取所述计算机可读指令并实现权利要求1-4中任意一项所述的能力管理方法。

6.一种计算机程序产品，其特征在于，所述计算机程序产品计算机可读指令，当所述计算机可读指令被一个或多个处理器运行时实现权利要求1-4中任意一项所述的能力管理方法。

7.根据权利要求6所述的计算机程序产品，其特征在于，所述计算机程序产品为操作系统或操作系统的内核。

8.一种能力管理方法，其特征在于，包括：

授权者向内核发送授权请求，所述授权请求中包括授权参数，所述授权参数用于指示待授权的能力；所述授权请求用于指示所述内核将所述待授权的能力授权给被授权者；

所述授权者获得所述内核返回的的回收参数，所述回收参数用于所述授权者管理本次授权。

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

所述授权者向所述内核发送回收请求，所述回收请求中包括所述回收参数，所述回收参数被所述内核用于执行能力回收。

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

所述被授权者向所述内核发送准备请求；

所述被授权者获得所述内核返回的放弃参数，所述放弃参数用于所述被授权者管理被授权的所述能力。

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

所述被授权者向所述内核发送放弃请求，所述放弃请求中包含所述放弃参数，所述放弃参数被所述内核用于执行能力放弃。

12.一种计算机设备，其特征在于，所述计算机设备包括存储器和处理器，所述存储器用于存储计算机可读指令，所述处理器用于读取所述计算机可读指令并实现权利要求8-11中任意一项所述的能力管理方法。

13.一种计算机程序产品，其特征在于，所述计算机程序产品计算机可读指令，当所述计算机可读指令被一个或多个处理器运行时实现权利要求8-11中任意一项所述的能力管理方法。

14.根据权利要求13所述的计算机程序产品，其特征在于，所述计算机程序产品为在用户态运行的应用。

Images