On Thu, Sep 04, 2025 at 04:04:51PM +0200, Miklos Szeredi wrote: > On Thu, 21 Aug 2025 at 02:53, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > #endif /* _FS_FUSE_I_H */ > > diff --git a/fs/fuse/fuse_trace.h b/fs/fuse/fuse_trace.h > > index bbe9ddd8c71696..2389072b734636 100644 > > --- a/fs/fuse/fuse_trace.h > > +++ b/fs/fuse/fuse_trace.h > > One general thing I'd like to ask is that debugging and tracing be as > much separated from actual functionality as possible. Not just on the > source tree level but on the patch or even patchset level, please. How would that work in practice for this patch? One way I can think of to break up this patch would be: Patch 1 introduces all the #defines that later get used by the #define FOO_STRINGS that get passed to __print_symbolic/__print_flags macros. Patch 2 defines the tracepoints and ASSERT/BAD_DATA Patch 3 adds all the new code that actually uses ASSERT/BAD_DATA and calls trace_fuse_iomap_XXX() ...or would you prefer patch 3 to be code only, and a patch 4 would dump in all the assertions and tracepoint callsites separately? For subsequent patches that add new iomap flags (and hence extend FOO_STRINGS) and tracepoints, should those also go in a separate pre-patch ahead of the actual code using it? Or do you prefer the first N patches to include only code and no debugging stuff at all, with a megapatch at the end to add all that instrumentation? (Or would you rather I sorted the diff chunks to put fuse_trace.h at the very end of each patch, because AFAICT reviewers rarely spend much time looking at the tracepoints and at least then you don't have to scroll through that boilerplate to get to the real code...) Yeah, I know, the ftrace macros are painful to look at and wish there was a better way to do that. --D > Thanks, > Miklos >
