Quoting Sean Paul (2019-10-10 23:48:08) > From: Sean Paul <seanpaul@xxxxxxxxxxxx> > > *Record scratch* You read that subject correctly, I bet you're wondering > how we got here. At least hear me out before you flame :-) > > For a long while now, we (ChromeOS) have been struggling getting any > value out of user feedback reports of display failures (notably external > displays not working). The problem is that all logging, even fatal > errors (well, fatal in the sense that a display won't light up) are > logged at DEBUG log level. So in order to extract these logs, you need > to be able to turn on logging, and reproduce the issue with debug > enabled. Unfortunately, this isn't really something we can ask CrOS users > I spoke with airlied about this and RHEL has similar issues. > > This is the point where you ask me, "So Sean, why don't you just enable > DRM_UT_BLAH?". Good question! Here are the reasons in ascending order of > severity: > 1- People aren't consistent with their categories, so we'd have to > enable a bunch to get proper coverage > 2- We don't want to overwhelm syslog with drm spam, others have to use > it too > 3- Console logging is slow > > Hopefully you're with me so far. I have a problem that has no existing > solution. What I really want is a ringbuffer of the most recent logs > (in the categories I'm interested in) exposed via debugfs so I can > extract it when users file feedback. A nitpick, tracepoints are no longer in debugfs but tracefs. I'm being told the reason is because production environments want to use them and expect them to be stable. > It just so happens that there is something which does _exactly_ this! I > can dump the most recent logs into tracepoints, turn them on and off > depending on which category I want, and pull them from debugfs on demand. > > "What about trace_printk()?" You'll say. It doesn't give us the control we > get from using tracepoints and it's not meant to be left sprinkled around > in code. > > So that is how we got here, now it's time for you to tell me why this is > a horrible idea :-) Being devil's advocate; How long until all our debugging messages will be kernel ABI? In the context of the DRM subsystem level unified tracing (Message-Id: 20190121232040.26114-1-chris@xxxxxxxxxxxxxxxxxx) we already struggled to find the sweet spot of exposing only information we can maintain long term. I can imagine this de-railing into to a direction when the userspace debugging information of interest is extracted from the kernel debug messages. When that message format changes and breaks the userspace tool, you probably know the drill. I like the base idea, but implementation through tracepoints has great potential to become maintenance nightmare. So maybe something actually in debugfs might be the right solution? Regards, Joonas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
