为什么要进行数字版权管理渲染节点从 128开始/dev/dri/renderD<X>
编号,而特权接口从/dev/dri/card<X>
0 开始?
$ ls -al /dev/dri/
total 0
drwxr-xr-x 3 root root 100 Nov 21 07:46 .
drwxr-xr-x 23 root root 6040 Nov 22 11:09 ..
drwxr-xr-x 2 root root 80 Nov 21 07:46 by-path
crw-rw----+ 1 root video 226, 0 Nov 21 07:46 card0
crw-rw----+ 1 root render 226, 128 Nov 21 07:46 renderD128
答案1
特权DRI接口首先出现,最初为它们分配了固定的主设备号226只。
随着 ARM 设备和 GPGPU 计算设备的发展证明,显示模式设置和渲染需要作为单独的设备进行访问,开发渲染节点。看起来 128 以上的次要设备编号是为它们分配的,尽管我无法很快找到任何明确说明这一点的文档。
分配设备编号的代码开始于drm_dev_init()
函数drivers/gpu/drm/drm_drv.c
在内核源代码中。开始于631号线它称为drm_minor_alloc
同一文件中的函数:
if (drm_core_check_feature(dev, DRIVER_RENDER)) {
ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
if (ret)
goto err;
}
ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
if (ret)
goto err;
它称为idr_alloc()
在lib/idr.c
:
r = idr_alloc(&drm_minors_idr,
NULL,
64 * type,
64 * (type + 1),
GFP_NOWAIT);
的参数为idr_alloc()
:
* idr_alloc() - Allocate an ID.
* @idr: IDR handle.
* @ptr: Pointer to be associated with the new ID.
* @start: The minimum ID (inclusive).
* @end: The maximum ID (exclusive).
* @gfp: Memory allocation flags.
如果驱动程序支持该DRIVER_RENDER
功能并因此支持渲染节点,idr_alloc
则会调用两次以首先分配渲染节点,然后分配主节点。否则仅分配主节点。
常量DRM_MINOR_*
定义在include/drm/drm_file.h
:
/* Note that the order of this enum is ABI (it determines
* /dev/dri/renderD* numbers).
*/
enum drm_minor_type {
DRM_MINOR_PRIMARY,
DRM_MINOR_CONTROL,
DRM_MINOR_RENDER,
};
由于这是一个enum
,DRM_MINOR_PRIMARY
因此其值为 0,分别DRM_MINOR_CONTROL
为 1 和DRM_MINOR_RENDER
2。
这可以将 0 <= x < 64 范围内的次要设备编号分配给主接口节点,将 64 <= x < 128 分配给 DRM_MINOR_CONTROL 节点(无论它们是什么......目前似乎在 6.0.x 内核中未使用?)和 128 <= x < 192 到 DRM_MINOR_RENDER 节点。
然后将设备的 sysfs 名称分配给drivers/gpu/drm/drm_sysfs.c
在函数中drm_sysfs_minor_alloc()
,只需使用次设备号作为名称的一部分:
if (minor->type == DRM_MINOR_RENDER)
minor_str = "renderD%d";
else
minor_str = "card%d";
[...]
r = dev_set_name(kdev, minor_str, minor->index);
并且除非udev
使用规则来修改默认设备名称,否则 sysfs 名称也会成为设备节点的名称。
基本上,这是因为到目前为止,没有人愿意添加一个条件子句,在分配默认设备名称(如果它是渲染节点)时,该条件子句会从次要设备节点号中减去 128。
另外,请注意这篇 2013 年 DRM 开发博客文章说:
了解渲染节点也很重要 不是绑定到特定的卡。虽然在内部它是由与遗留节点相同的驱动程序创建的,但用户空间永远不应该假设渲染节点和遗留/模式设置节点之间有任何连接。相反,如果用户空间需要硬件加速,则应该打开 任何 节点并使用它。
[...]
诸如“如何找到给定卡的渲染节点?”之类的问题没有任何意义。是的,特定于驱动程序的用户空间可以确定哪个渲染节点是否由哪个驱动程序创建以及哪个渲染节点是由哪个驱动程序创建的,但非特定于驱动程序的用户空间永远不应该这样做!
考虑到这一意图,选择故意从 128 开始对渲染节点进行编号(以打破card0
和renderD0
始终引用同一张卡的潜在错误假设)可能是有意义的。