linux-kernel - Re: [PATCH v1] dynamic_debug: add support for logs destination

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231012133944.69711822@eldfell>
Date:   Thu, 12 Oct 2023 13:39:44 +0300
From:   Pekka Paalanen <ppaalanen@...il.com>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     jim.cromie@...il.com,
        Łukasz Bartosik <lb@...ihalf.com>,
        linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
        "wayland-devel@...ts.freedesktop.org" 
        <wayland-devel@...ts.freedesktop.org>,
        Sean Paul <seanpaul@...omium.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v1] dynamic_debug: add support for logs destination

On Thu, 12 Oct 2023 11:53:52 +0200
Daniel Vetter <daniel@...ll.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@...ll.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

Content of type "application/pgp-signature" skipped