Historically, we have avoided adding tracepoints to the VFS because of concerns that tracepoints would be considered a userspace-level interface, and would therefore potentially constrain our ability to improve an interface which has been extremely performance critical. I'd like to discuss whether in 2025, it's time to reconsider our reticence in adding tracepoints in the VFS layer. First, while there has been a single incident of a tracepoint being used by programs that were distributed far and wide (powertop) such that we had to revert a change to a tracepoint that broke it --- that was ***14** years ago, in 2011. Across multiple other subsystems, many of which have added an extensive number of tracepoints, there has been only a single problem in over a decade, so I'd like to suggest that this concern may have not have been as serious as we had first thought. In practice, most tracepoints are used by system administrators and they have to deal with enough changes that break backwards compatibility (e.g., bash 3 ->bash 4, bash 4 -> bash 5, python 2.7 -> python 3, etc.) that the ones who really care end up using an enterprise distribution, which goes to extreme length to maintain the stable ABI nonsense. Maintaining tracepoints shouldn't be a big deal for them. Secondly, we've had a very long time to let the dentry interface mature, and so (a) the fundamental architecture of the dcache hasn't been changing as much in the past few years, and (b) we should have enough understanding of the interface to understand where we could put tracepoints (e.g., close to the syscall interface) which would make it much less likely that there would be any need to make backwards-incompatible changes to tracepoints. The benefits of this would be to make it much easier for users, developers, and kernel developers to use BPF to probe file system-related activities. Today, people who want to do these sorts of things need to use fs-specific tracepoints (for example, ext4 has a very large number of tracepoints which can be used for this purpose) but this locks users into a single file system and makes it harder for them to switch to a different file system, or if they want to use different file systems for different use cases. I'd like to propose that we experiment with adding tracepoints in early 2025, so that at the end of the year the year-end 2025 LTS kernels will have tracepoints that we are confident will be fit for purpose for BPF users. Thanks, - Ted
