On Thu, 12 Oct 2023 11:53:52 +0200 Daniel Vetter <dan...@ffwll.ch> 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 <dan...@ffwll.ch> 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
pgpGben6913p0.pgp
Description: OpenPGP digital signature
