I was trying to use an eBPF script to dump all paths being created, opened, modified, or deleted. I hit a wall when I couldn't figure out how to extract the actual path from anything and figured exposing dentry_path_raw as a BPF-accessible function would do it. I was thinking of sending this code upstream, and I've included a patch, but I figure I should ask some questions first: 1. Is this even the right place to be asking all this? I assume the d_path.c maintainers would also have a word or two (probably linux-fsdevel), but I'm focusing on if these kfuncs are even sensible. 2. Actually, could I have gotten the path from something without writing any new code in the first place? I was kprobing various vfs_* functions that would give me a dentry*. 3. What's the etiquette on ignored pointers? I'm designating the dentry* as an ignored type. 4. Should functions like this hide behind a build configuration constant? 5. What would be the proper workflow for formally submitting it as a patch? Is this mailing list the best entryway? I expect actual file maintainers have final say, but I wonder if other people get brought in for BPF stuff. This patch is based off my work on 6.13, but applies and on 6.15 (based on 8bac8898fe398ffa3e09075ecea2be511725fb0b). An allyesconfig build pukes at the vmlinux.o creation because 6.15 is really big for some reason, and it does that for me regardless.
