On Fri, Jan 23, 2026 at 01:26:45PM +0100, Gabriele Monaco wrote: > On Fri, 2026-01-23 at 09:19 -0300, Wander Lairson Costa wrote: > > On Thu, Jan 22, 2026 at 02:49:59PM +0100, Gabriele Monaco wrote: > > > Why fill_tracepoint_args_skel() is not required by LTL is an > > > implementation > > > detail, so that stub could even stay, in case future monitors are going to > > > need > > > the entire thing. > > > Though I still find it cleaner to move that away too until there's a need > > > for it > > > shared in Monitor. > > > > I didn't catch what is included in "that"... > > Right, it ended up quite cryptic, I meant fill_tracepoint_args_skel() could > stay > in Monitor although not all Monitors need it, though I honestly prefer to move > it away and not rely on the stub. > > > > What do you think? > > > > I agreed. fill_tracepoint_args_skel() makes sense in the Monitor class. > > If a derived class doesn't need it, it is an implementation detail. > > > > But I get your stance and agree with that too, where > fill_tracepoint_args_skel() > goes is just nitpicking at this point. >
I will go with your early suggestion and drop all this related work in v2 and submitting a separate patch series addressing these interface issues. Python has some good tools [1,2] to handle that. I intend to make use of them. [1] https://docs.python.org/3/library/abc.html [2] https://typing.python.org/en/latest/spec/protocol.html > Thanks, > Gabriele >
