xf86drm: Add drmHandleMatch func

PATCH In review Robert Foss 2 participants 3 messages Apr 27, 2018 – Apr 30, 2018

lore

Share & tools

lore

Robert Foss

author

2018-04-27 11:31 UTC #0 lore raw

PATCH 1/1 xf86drm: Add drmHandleMatch func

drmHandleMatch is intended to allow for userspace to filter out devices that it does not want to open.

Opening specific devices using paths alone is not a reliable due to probing order. This function intends to provide a mechanism for filtering out devices that don't fit what you need using an extensible set of filters.

drm_match_key_t is intended to be extended with whatever filter that would come in handy down the line.

As a catch-all filter, the DRM_MATCH_FUNCTION was included which allows the caller to filter based on an arbitrary function.

An function pointer filter could of course filter based on anything. But for the sake of convenience a few other simple filters have been included.

If the function pointer filter ends up being called with a boilerplate fp by mutliple libdrm users, perhaps that funtion could be moved into libdrm at a future date.

Signed-off-by Robert Foss <[email protected]>

---

This patch implements a simple function for matching DRM device FDs against the desired properties of a device that you are looking for.

The discussion that led to this series can be found here:
https://lists.freedesktop.org/archives/mesa-dev/2018-January/183878.html

The RFC can be found here:
https://www.spinics.net/lists/dri-devel/msg172398.html

Since the RFC I opted to rework the patch to be more extensible. The previous implementation would have been problematic if the drmVersion or drmDevice structs ever needed to be changed or removed. Or indeed if more properties were to become interesting.

As it is now, it is basially implemented as per Daniel Stones suggestion in the RFC discussion.

Changes since RFC:
- Reworked proposal to be not be based on structs in order to be more flexible.
- Now uses filters of different types.
- Caller can supply any number of predefined and function pointer filter.

 xf86drm.h     | 24 ++++++++++++++++++++
 xf86drmMode.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 94 insertions(+)

xf86drm.h +24 -0

index 7773d71a8030..71bf39baf9b2 100644
@@ -863,6 +863,30 @@ extern int drmGetDevices2(uint32_t flags, drmDevicePtr devices[], int max_device
 
 extern int drmDevicesEqual(drmDevicePtr a, drmDevicePtr b);
 
+typedef enum drm_match_key {
+	/* Match against DRM_NODE_{PRIMARY,RENDER,...} type */
+    DRM_MATCH_NODE_TYPE = 1,
+    DRM_MATCH_DRIVER_NAME = 2,
+	DRM_MATCH_BUS_PCI_VENDOR = 3,
+	DRM_MATCH_FUNCTION = 4,
+} drm_match_key_t;
+
+typedef struct drm_match_func {
+	void *data;
+	int (*fp)(int, void*); /* Intended arguments are fp(fd, data) */
+}	drm_match_func_t;
+
+typedef struct drm_match {
+	drm_match_key_t type;
+	union {
+		int s;
+		uint16_t u16;
+		char *str;
+		drm_match_func_t func;
+	};
+} drm_match_t;
+extern int drmHandleMatch(int fd, drm_match_t *filters, int nbr_filters);
+
 extern int drmSyncobjCreate(int fd, uint32_t flags, uint32_t *handle);
 extern int drmSyncobjDestroy(int fd, uint32_t handle);
 extern int drmSyncobjHandleToFD(int fd, uint32_t handle, int *obj_fd);

xf86drmMode.c +70 -0

76 lines not on this page · raw message

Signature · 6 lines

2.14.1

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Emil Velikov

2018-04-27 13:48 UTC #1 lore raw

Quoted 49 lines · Robert Foss

drmHandleMatch is intended to allow for userspace to filter out devices that it does not want to open.
Opening specific devices using paths alone is not a reliable due to probing order. This function intends to provide a mechanism for filtering out devices that don't fit what you need using an extensible set of filters.
drm_match_key_t is intended to be extended with whatever filter that would come in handy down the line.
As a catch-all filter, the DRM_MATCH_FUNCTION was included which allows the caller to filter based on an arbitrary function.
An function pointer filter could of course filter based on anything. But for the sake of convenience a few other simple filters have been included.
If the function pointer filter ends up being called with a boilerplate fp by mutliple libdrm users, perhaps that funtion could be moved into libdrm at a future date.
Signed-off-by Robert Foss <[email protected]>
---
This patch implements a simple function for matching DRM device FDs against the desired properties of a device that you are looking for.
The discussion that led to this series can be found here:
https://lists.freedesktop.org/archives/mesa-dev/2018-January/183878.html
The RFC can be found here:
https://www.spinics.net/lists/dri-devel/msg172398.html
Since the RFC I opted to rework the patch to be more extensible. The previous implementation would have been problematic if the drmVersion or drmDevice structs ever needed to be changed or removed. Or indeed if more properties were to become interesting.
As it is now, it is basially implemented as per Daniel Stones suggestion in the RFC discussion.
Changes since RFC:
- Reworked proposal to be not be based on structs in order to be more flexible.
- Now uses filters of different types.
- Caller can supply any number of predefined and function pointer filter.

Quoted 4 lines

 xf86drm.h     | 24 ++++++++++++++++++++
 xf86drmMode.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 94 insertions(+)

Instead of spending too much time thinking of a future-proof API, can I suggest getting a handful of users first.
And only after that lifting it to a helper - If needed.

Here are some examples - anv [1] and xf86-video-amdgpu [2]. Note latter is not merged yet.
Practically any implementation is as trivial as:

ret = drmGetDevices2(...)
for (i = 0; i < ret; i++) {
compare_device_specifics(...)
}
drmFreeDevices(...)

What do you guys think?
Emil

[1] https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/anv_device.c#n615
[2] https://lists.freedesktop.org/archives/amd-gfx/2018-April/020936.html
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Robert Foss

author

2018-04-30 08:05 UTC #2 lore raw

Hey Emil,

Quoted 62 lines · Emil Velikov

Quoted 49 lines · Robert Foss
drmHandleMatch is intended to allow for userspace to filter out devices that it does not want to open.
Opening specific devices using paths alone is not a reliable due to probing order. This function intends to provide a mechanism for filtering out devices that don't fit what you need using an extensible set of filters.
drm_match_key_t is intended to be extended with whatever filter that would come in handy down the line.
As a catch-all filter, the DRM_MATCH_FUNCTION was included which allows the caller to filter based on an arbitrary function.
An function pointer filter could of course filter based on anything. But for the sake of convenience a few other simple filters have been included.
If the function pointer filter ends up being called with a boilerplate fp by mutliple libdrm users, perhaps that funtion could be moved into libdrm at a future date.
Signed-off-by Robert Foss <[email protected]>
---
This patch implements a simple function for matching DRM device FDs against the desired properties of a device that you are looking for.
The discussion that led to this series can be found here:
https://lists.freedesktop.org/archives/mesa-dev/2018-January/183878.html
The RFC can be found here:
https://www.spinics.net/lists/dri-devel/msg172398.html
Since the RFC I opted to rework the patch to be more extensible. The previous implementation would have been problematic if the drmVersion or drmDevice structs ever needed to be changed or removed. Or indeed if more properties were to become interesting.
As it is now, it is basially implemented as per Daniel Stones suggestion in the RFC discussion.
Changes since RFC:
- Reworked proposal to be not be based on structs in order to be more flexible.
- Now uses filters of different types.
- Caller can supply any number of predefined and function pointer filter.
Quoted 4 lines
  xf86drm.h     | 24 ++++++++++++++++++++
  xf86drmMode.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 94 insertions(+)
Instead of spending too much time thinking of a future-proof API, can I suggest getting a handful of users first.
And only after that lifting it to a helper - If needed.
Here are some examples - anv [1] and xf86-video-amdgpu [2]. Note latter is not merged yet.
Practically any implementation is as trivial as:

Quoted 7 lines

ret = drmGetDevices2(...)
for (i = 0; i < ret; i++) {
compare_device_specifics(...)
}
drmFreeDevices(...)
What do you guys think?

I was hoping to have all probing functionality eventually implemented in libdrm, since it is duplicated in multiple codebases. Where this function&patch would be the first step.

But there seems to be some friction to this idea, so maybe it dropping this patch is the way to go forward.

Quoted 9 lines

Emil
[1] https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/anv_device.c#n615
[2] https://lists.freedesktop.org/archives/amd-gfx/2018-April/020936.html
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel