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:
pgpqSAL6wyq6y.pgp
Description: OpenPGP digital signature
