On Thu, Oct 12, 2023 at 01:39:44PM +0300, Pekka Paalanen wrote: > 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. I actually pondered this a bit more today, and I think even with hindsight the atomic design we ended up with was probably rather close to optimal. Sure there's a bunch of things that would have been nice to include, but another very hard requirement of atomic was that it's feasible to convert current drivers over to it. And I think going full free-standing state structures with unlimited (at least at the design level) queue depth would have been a bridge too far. The hacks and conversion helpers are all gone by now, but "you can just peek at the object struct to get your state" was a huge help in reducing the conversion churn. But it definitely resulted in a big price we're still paying. tldr I don't think getting somewhere useful, even if somewhat deficient, is bad. -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
