[igt-dev] [PATCH i-g-t] xe_live_ktest: Use xe_live_test kernel module

[Mauro Carvalho Chehab]

On Tue, 16 Jan 2024 08:50:51 -0600
Lucas De Marchi <lucas.demarchi at intel.com> wrote:

> On Mon, Jan 15, 2024 at 08:52:07PM +0100, Mauro Carvalho Chehab wrote:
> >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.  
> 
> ftrace provides a way for you to read the format of the tracepoint and
> use it (API). If you did it otherwise and hardcoded the format (ABI),
> you are on your own as tracepoints in the kernel keep changing.
> Try grepping "tracepoint" in the last pull requests.

Not quite true. Since when the EDAC subsystem was redesigned back
in 2013, RAS events have been using ftrace API to report hardware
problems to userspace. We did the design of such API together with the
ftrace maintainer, that developed an userspace counterpart (libtraceevent),
designed to have a stable uABI. 

The rasdaemon application uses it since then, originally on a fork, as 
it took a while for libtraceevent to become a separate tree and started
being shipped in distributions. Only last year we finally migrated to use
the current incarnation of libtraceevent, mostly to cleanup rasdaemon code.

During all this time (10+ years), the API remained the same, and we had
only once an incident on such interface - not directly related to uABI,
but to some behavioral change that happened at the logic to flush
ftrace ringbuffer, causing troubles for rasdaemon.

Regards,
Mauro