> If you want the kernel to keep separate flight recorders I guess we could > add that, but I don't think it currently exists for the dyndbg stuff at > least. Maybe a flight recorder v2 feature, once the basics are in. > dyndbg has +p writes to syslog +T would separately independently write the same to global trace This would allow graceful switchover to tracefs, without removing logging from dmesg, where most folks (and any monitor tools) would expect it. Lukas (iiuc) wants to steer each site to just 1 destination. Or maybe (in addition to +p > syslog) one trace destination, either global via events, or a separate tracebuf Im ambivalent, but thinking the smooth rollover from syslog to trace might be worth having to ease migration / weaning off syslog. And we have a 4 byte hole in struct _ddebug we could just use. Unless the align 8 is optional on 32-bits, I think we're never gonna close the hole anywhere. is align 8 a generic expression of an architectural simplifying constraint ? or a need for 1-7 ptr offsets ? > > That's my idea of it. It is interesting to see how far the requirements > > can be reasonably realised. > > I think aside from the "make it available directly to unpriviledged > userspace" everything sounds reasonable and doable. > > More on the process side of things, I think Jim is very much looking for > acks and tested-by by people who are interested in better drm logging > infra. That should help that things are moving in a direction that's > actually useful, even when it's not yet entirely complete. > yes, please. Now posted at https://lore.kernel.org/lkml/20231012172137.3286566-1-jim.cromie@xxxxxxxxx/T/#t Lukas, I managed to miss your email in the send phase. please consider yourself a direct recipient :-) thanks everyone > Cheers, Sima > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
