On Tue, Jul 1, 2025 at 11:58 PM Steven Rostedt <rost...@goodmis.org> wrote: > > On Fri, 20 Jun 2025 15:26:27 +0200 > Gabriele Paoloni <gpaol...@redhat.com> wrote: > > > I think that from my side I do not have comprehensive answers to all your > > questions (I need to read the code more in depth). > > So to be pragmatic I can split this effort into two parts (documentation and > > redesign); I will propose documentation first with the TIPs that you > > mentioned > > above and later, if we find a better re-design solution, we can also amend > > the documentation as needed. > > Just to confirm, I agree with Masami. The enable file is quite special, > and I don't see the use of user space playing tricks with it, which > even includes lseek. Maybe to keep rewinding a read to get a new status > change?
Well the proposed patchset was aiming to prevent the user from doing stupid things (e.g. reading 1byte at a time or reading after a write has increased ppos). However documenting the correct AoUs would still work > > But it usually contains a single character (sometimes two) and a new > line. It's not something that's ever been reported as an issue. I > rather not touch it if it hasn't been reported as broken because > there's some hypothetical use case that can see it as broken. > > Documenting its current behavior is perfectly fine with me. Yep "[RFC PATCH v3] tracing: add testable specifications for event_enable_write/read" is already out. Thanks Gab > > -- Steve >
