[igt-dev] [PATCH i-g-t] xe_live_ktest: Use xe_live_test kernel module
Mauro Carvalho Chehab
mauro.chehab at linux.intel.com
Mon Jan 15 19:52:07 UTC 2024
On Mon, 15 Jan 2024 09:21:35 +0200
Jani Nikula <jani.nikula at linux.intel.com> wrote:
> On Mon, 15 Jan 2024, Mauro Carvalho Chehab <mauro.chehab at linux.intel.com> wrote:
> > On 1/12/24 15:29, Lucas De Marchi wrote:
> >>> On such case, you should document kunit_debugfs at Documentation/ABI.
> >>
> >> debugfs is not part of ABI.
> >
> > That's arguable. Check Documentation/ABI and you'll see several debugfs
> > nodes documented there.
>
> I guess you could argue documenting your debugfs under Documentation/ABI
> makes it ABI, but I'd avoid doing that. Usually we use debugfs precisely
> to avoid the burden of ABI and all the baggage that brings.
Placing things at debugfs "precisely to avoid the burden of ABI and all
the baggage that brings" sounds a bad practice to me, but you can ask
others at LKML and see if this is a acceptable.
My understanding is that, if userspace tools rely on what's there at
debugfs, and a change break such tools, there is a high chance that
such change will end being reverted - at best, it will surely provide
some flame wars.
I remember we had some troubles related to trace logic in the past,
due to something similar: even not originally meant to provide a stable
ABI, and being under debugfs, there were some changes breaking userspace
which caused lots of discussions. Can't remember anymore if the changes
were reverted or not, but at the end ftrace ABI was considered as stable.
I have an userspace program which depends on it (rasdaemon).
Also, having it documented or not doesn't mean it is not ABI. See, for
instance, this article: https://lwn.net/Articles/309298/.
Regards,
Mauro
More information about the Intel-xe
mailing list