On Fri, Sep 12, 2025 at 03:28:17PM +0200, Miklos Szeredi wrote:
> On Thu, 11 Sept 2025 at 23:45, Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
>
> > So I think the third approach is the way to go, but I'd like your input
> > before I commit to a particular approach.
>
> Okay.
>
> I'm not going to rant against tracepoints, because I'm sure you have a
> good reason to bear the pain of dealing with them. I'd just like to
> minimise the pain for myself and other reviewers. If I can just
> ignore clearly marked tracing patches, that seems good enough.
Ah, ok. Knowing your motivation helps me a lot, thanks for letting me
know. I'll keep the tracing code as separate as possible, then.
<begin rant>
FYI: I don't like the way tracepoints are composed either. Nested C
preprocessor macros are both too clever and require too much cleverness
for my taste, but I'm addicted to tracing data flows, so I'm stuck with
their current pain until someone makes it as easy as:
trace_fuse_iomap_begin(const struct inode *inode, loff_t pos,
loff_t count, const struct iomap *iomap) =>
"{inode->ino} {pos} {count} {iomap->offset}..."
and have it generate the necessary data structures and trace printk
strings from that. But you can only do such things if macros can
perform AST transformations in the compiler, and /that/ wasn't around in
1969. :(
<end rant>
--D
> Thanks,
> Miklos
