On 8/27/25 11:09, Mario Limonciello wrote:
On 8/27/2025 11:41 AM, Lizhi Hou wrote:
On 8/26/25 17:31, Mario Limonciello wrote:
On 8/26/2025 1:10 PM, Lizhi Hou wrote:
On 8/26/25 10:58, Mario Limonciello wrote:
On 8/26/2025 12:55 PM, Lizhi Hou wrote:
On 8/26/25 10:18, Mario Limonciello wrote:
On 8/25/2025 11:48 PM, Lizhi Hou wrote:
On 8/25/25 14:28, Mario Limonciello wrote:
On 8/22/2025 12:23 PM, Lizhi Hou wrote:
Add interface for applications to get information array. The
application
provides a buffer pointer along with information type,
maximum number of
entries and maximum size of each entry. The buffer may also
contain match
conditions based on the information type. After the ioctl
completes, the
actual number of entries and entry size are returned.
Signed-off-by: Lizhi Hou <lizhi....@amd.com>
How does userspace discover whether or not the new IOCTL call
is supported? Just a test call?
The kernel header version will be used to determine whether the
application which uses new IOCTL will be compiled or not.
But it's not actually an application compile time decision, it's
a runtime decision. IE I can compile an application with the
headers on kernel 6.18 that has this, but if I try to run it on
6.15 it's going to barf.
To some extent that comes with the territory, but I'm wondering
if a better solution going forward would be for there to be a
dedicated version command that you bump.
For in-tree driver, I did not aware a common way for this other
than checking the kernel version.
And here is qaic patch of adding a new IOCTL.
https://github.com/torvalds/linux/
commit/217b812364d360e1933d8485f063400e5dda7d66
I know there is major, minor, patchlevel in struct drm_driver.
And I think that is not required for in-tree driver.
Please let me know if I missed anything.
Thanks,
Right; so bump up one of those so that userspace can check it.
Maybe "minor"?
I meant for in-tree driver, is it good enough for userspace to just
check kernel version? E.g. The drm driver versions are not used by
ivpu or qaic.
Just because they don't doesn't mean you shouldn't.
Ok. :) It does not sound amdxdna specific. Just wondering how the
other driver/application under accel subsystem handle this.
Take a look at what amdgpu does for user queues earlier this year
for example: 100b6010d7540e
This means that a userspace application can look for that minor bump
or newer to know the ioctl supports user queues.
As in-tree driver is part of kernel, the userspace application can
check kernel version to determine whether a feature is supported or
not. Could you share the idea why would user application to check drm
driver version for this?
And amdxdna driver is new added driver which never bumped drm major/
minor before. Thus there is not any application use drm versions.
Maybe using kernel version directly is good enough in this case?
I am fine to bump minor if it provides better support to user
applications.
Thanks,
Lizhi
If you're running mainline kernel I totally agree with you that you
can make a runtime call based upon major/minor kernel version. To me
the problem ends up being cases that distros do a backport of a driver
or subsystem that this falls apart.
For example RHEL and CentOS stream both do this, and then such
comparisons can no longer be made accurately.
Ok. I will bump minor by 1.
Lizhi
