Formalizing the kernel module ABI#83
Conversation
Signed-off-by: Jan-Oliver Opdenhövel <jopdenho@amd.com>
Signed-off-by: Jan-Oliver Opdenhövel <jopdenho@amd.com>
… into docs/ioctl_protocol
Signed-off-by: Jan-Oliver Opdenhövel <jopdenho@amd.com>
Signed-off-by: Jan-Oliver Opdenhövel <jopdenho@amd.com>
Signed-off-by: Jan-Oliver Opdenhövel <jopdenho@amd.com>
Signed-off-by: Jan-Oliver Opdenhövel <jopdenho@amd.com>
Signed-off-by: Jan-Oliver Opdenhövel <jopdenho@amd.com>
Signed-off-by: Jan-Oliver Opdenhövel <jopdenho@amd.com>
| never freed. This stability guarantee means ``/dev/slash_ctl0`` always refers to the same physical | ||
| card across remove+rescan cycles. However, suffixes for one card are not guaranteed to be identical | ||
| for ``/dev/slash_ctl<N>`` and ``/dev/slash_qdma_ctl<N>`` since they represent separate physical | ||
| functions and thus BDFs. |
There was a problem hiding this comment.
I don't think this should be documented. Consumers should just use BDFs and not rely on this behaviors.
There was a problem hiding this comment.
I think, the stability of the BDF-to-number mapping should be documented. If it's not and you're playing by the book, you would need to re-check the BDF of the device you've opened every single time you're re-opening it. I'm with you that users should not rely on any assumptions how the mapping is created, but I think they should be able to rely on the fact that once mappings exist, they are permanent. Or would you just prefer the statement that mappings may not be stable across remove+rescan cycles?
There was a problem hiding this comment.
Software should always use BDF for identity across resets. The only reason I implemented number stability was to avoid /dev/slash_ctl400, which looks silly.
There was a problem hiding this comment.
Okay, that's sensible. I've adapted the documentation accordingly.
Signed-off-by: Jan-Oliver Opdenhövel <jopdenho@amd.com>
Signed-off-by: Jan-Oliver Opdenhövel <jopdenho@amd.com>
2 participants
This PR introduces a formalization of the kernel module ABI. Currently, this covers a specification guide in the reference section of the documentation, but I would also like to include an extended testing suite, covering the formalized understanding of the interface between kernel space and user space.