Messages in this thread | | | Date | Thu, 12 Oct 2023 13:39:44 +0300 | From | Pekka Paalanen <> | Subject | Re: [PATCH v1] dynamic_debug: add support for logs destination |
| |
On Thu, 12 Oct 2023 11:53:52 +0200 Daniel Vetter <daniel@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 <daniel@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 [unhandled content-type:application/pgp-signature] | |