On August 28, 2025 3:39:35 PM GMT-03:00, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >On Thu, 28 Aug 2025 at 11:05, Steven Rostedt <rostedt@xxxxxxxxxx> wrote: >> >> The deferred user space stacktrace event already does a lookup of the vma >> for each address in the trace to get the file offset for those addresses, >> it can also report the file itself. > >That sounds like a good idea.. > >But the implementation absolutely sucks: > >> Add two more arrays to the user space stacktrace event. One for the inode >> number, and the other to store the device major:minor number. Now the >> output looks like this: > >WTF? Why are you back in the 1960's? What's next? The index into the >paper card deck? > >Stop using inode numbers and device numbers already. It's the 21st >century. No, cars still don't fly, but dammit, inode numbers were a >great idea back in the days, but they are not acceptable any more. > >They *particularly* aren't acceptable when you apparently think that >they are 'unsigned long'. Yes, that's the internal representation we >use for inode indexing, but for example on nfs the inode is actually >bigger. It's exposed to user space as a u64 through > > stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode)); > >so the inode that user space sees in 'struct stat' (a) doesn't >actually match inode->i_ino, and (b) isn't even the full file ID that >NFS actually uses. > >Let's not let that 60's thinking be any part of a new interface. > >Give the damn thing an actual filename or something *useful*, not a >number that user space can't even necessarily match up to anything. > A build ID? PERF_RECORD_MMAP went thru this, filename -> inode -> Content based hash - Arnaldo
