fusefs: convert debug printfs into dtrace probes

[asomers]

Summary

fusefs: convert debug printfs into dtrace probes

fuse(4) was heavily instrumented with debug printf statements that could
only be enabled with compile-time flags. They fell into three basic groups:

1. Totally redundant with dtrace FBT probes. These I deleted.
2. Print textual information, usually error messages. These I converted to SDT probes of the form fuse:fuse:FILE:trace. They work just like the old printf statements except they can be enabled at runtime with dtrace. They can be filtered by FILE and/or by priority.
3. More complicated probes that print detailed information. These I converted into ad-hoc SDT probes.

Also, de-inline fuse_internal_cache_attrs.
It's big enough to be a regular function, and this way it gets a dtrace FBT
probe.

This commit is a merge of r345304, r344914, r344703, and r344664 from
projects/fuse2.

Test Plan

extensively tested already on the fuse2 branch

[cem]

I like the idea of converting the compile time debug prints into Dtrace SBT probes. But I’m not sure what the cache attribute function change has to do with these other logical changes.

[asomers]

In D19667#421605, @cem wrote:

I like the idea of converting the compile time debug prints into Dtrace SBT probes. But I’m not sure what the cache attribute function change has to do with these other logical changes.

You mean the de-inlineing of cache_attrs? I did that so it would get a dtrace fbt probe. I was pretty sure that I would want a probe in that position, and this seems easier and better than adding an SDT probe.

[cem]

In D19667#421646, @asomers wrote:

You mean the de-inlineing of cache_attrs? I did that so it would get a dtrace fbt probe. I was pretty sure that I would want a probe in that position, and this seems easier and better than adding an SDT probe.

Yeah. I guess that makes sense. Would it be reasonable to inline the fast path check (don’t cache && null outparam pointer)?

[asomers]

In D19667#421689, @cem wrote:

In D19667#421646, @asomers wrote:

You mean the de-inlineing of cache_attrs? I did that so it would get a dtrace fbt probe. I was pretty sure that I would want a probe in that position, and this seems easier and better than adding an SDT probe.

Yeah. I guess that makes sense. Would it be reasonable to inline the fast path check (don’t cache && null outparam pointer)?

On reflection, I think I'd rather not. I would have to inline almost half of the function.

[asomers]

update a comment.

[asomers]

Are you ok with this diff as-is, @cem?

[cem]

Sure