Re: [PATCH v1] dynamic_debug: add support for logs destination

[Pekka Paalanen]

On Thu, 12 Oct 2023 11:53:52 +0200
Daniel Vetter <daniel@xxxxxxxx> wrote:

> On Thu, Oct 12, 2023 at 11:55:48AM +0300, Pekka Paalanen wrote:
> > On Wed, 11 Oct 2023 11:42:24 +0200
> > Daniel Vetter <daniel@xxxxxxxx> wrote:
> >   
> > > On Wed, Oct 11, 2023 at 11:48:16AM +0300, Pekka Paalanen wrote:  

...

> > > > - all selections tailored separately for each userspace subscriber
> > > > (- per open device file description selection of messages)    
> > > 
> > > Again this feels like a userspace problem. Sessions could register what
> > > kind of info they need for their session, and something like journald can
> > > figure out how to record it all.  
> > 
> > Only if the kernel actually attaches all the required information to
> > the debug messages *in machine readable form* so that userspace
> > actually can do the filtering. And that makes *that* information UABI.
> > Maybe that's fine? I wouldn't know.  
> 
> Well if you configure the filters to go into separate ringbuffers for each
> session (or whatever you want to split) it also becomes uapi.

It's a different UAPI: filter configuration vs. message structure. I
don't mind which it is, I just suspect one is easier to maintain and
extend than the other.

> Also I'd say that for the first cut just getting the logs out on demand
> should be good enough, multi-gpu (or multi-compositor) systems are a step
> further. We can figure those out when we get there.

This reminds me of what you recently said in IRC about a very different
topic:

	<sima> swick[m], tell this past me roughly 10 years ago, would
	have been easy to add into the design back when there was no
	driver code yet 

I just want to mention today everything I can see as useful. It's up to
the people doing the actual work to decide what they include and how.


Thanks,
pq

Attachment: pgpg9BVusYULq.pgp
Description: OpenPGP digital signature