Re: New sysctl entry: proc.PID.realpath

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 07 Sep 2015 12:24:58 +0200
    From:        Kamil Rytarowski <n54%gmx.com@localhost>
    Message-ID:  <55ED65FA.1000702%gmx.com@localhost>

  | I'm here to get the support for it. At the moment it (cache nits)
  | exceeds my comprehension too.

What is the semantic you're hoping to provide?   The path that was used
to exec the process, or the path that would be used now to get the same
one?   [The difference is if the binary has been (re)moved between when
it was exec'd and now.]

The exec time path is easier, and must exist (or the exec would have
failed), the current path is more useful, but not guaranteed to exist,
and much harder to find.

Which is wanted depends upon what the real purpose of this is - if it is
just to replace the entry in /proc then before doing that ask what use
that has - does anything really use it, and if so, for what, and how well
does it work.

Others have been suggesting that the use is for debuggers (gdb or whatever).
If that's it, and the only reason, then personally I'd just forget it.
If someone is debugging a process, but can't even work out where the
binary is (or is too lazy to type it) then I'd suggest that they ought to
just give up...

On the other hand, if it is so the debugger can verify that it is working
from the correct binary file, then the pathname isn't needed, just the
<dev, ino> pair, which is the true name of a unix file (pathnames are
just a human interface improvement ... and a bit of added security).
With just that, the debugger can verify that the file running (assuming that
sysctl (or /proc) provide that info) is the one that the user told them is
to be debugged, and issue a warning (or whatever) if the don't match.

Alternatively, perhaps there's some other use ?

kre