Mike Coleman writes:
> Victor Zandy <zandy@cs.wisc.edu> writes:
> > Shouldn't it return EPERM instead?
>
> As far as I can see, it could have been done that way, and perhaps it should
> have, but it is documented.
I have only seen it documented in your (invaluable) revision of
the ptrace man page. Does your revision appear in major Linux
distributions yet?
> The current error scheme has a certain logic: You get EPERM when you don't
> have the right permissions, whereas you get ESRCH when you're trying to do
> something that's nonsense or impossible. (The exception is that you get EPERM
> if you try to trace an already traced process.)
In ptrace-land the line separating the forbidden from nonsense is
blurry. Is it really nonsense (or impossible) to detach from a
running process? Is it nonsense to do ptrace operations on a process
that is traced by another process, or just illegal? Your EPERM/ESRCH
distinction is coarse and subjective. Why not flag all errors,
bonkers or forbidden, with EPERM, and save ESRCH for when the process
really doesn't exist?
(Maybe that wouldn't be totally consistent with the ptrace of
other Unix kernels, but who cares? Isn't Linux the only one on which
ptrace is anything more than vestigial cruft?)
Anyhoo, I would be content if the ptrace man page explained that
"no such process" is not to be interpreted literally. Yours is fine,
but it didn't come with my Redhat 6.1 CDs.
Vic
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:24 EST