Discussion:
procfs ctl interface
Eric Badger
2017-02-25 01:43:32 UTC
Permalink
I started working on a change that will perturb procfs' ctl interface to
some degree. In looking closer at procfs, it seems like it has been
pretty well broken for use as a debugging interface since at least 9.3
(the oldest system I have handy). Is there any reason to maintain this
interface at all? If anything, it should perhaps be made into an
alternate front end for ptrace() rather than being entirely separate,
but I'm not sure I see the value in that.

Thanks for any thoughts/opinions.

Eric
Eric van Gyzen
2017-02-25 15:47:22 UTC
Permalink
I started working on a change that will perturb procfs' ctl interface to some
degree. In looking closer at procfs, it seems like it has been pretty well
broken for use as a debugging interface since at least 9.3 (the oldest system I
have handy). Is there any reason to maintain this interface at all? If anything,
it should perhaps be made into an alternate front end for ptrace() rather than
being entirely separate, but I'm not sure I see the value in that.
As I recall, the last in-tree consumer was gcore, but attilio@ switched it to
ptrace in r199805.

If nobody mentions a significant consumer, garbage-collecting it sounds good to me.

Eric
Eric Badger
2017-02-25 17:25:48 UTC
Permalink
I started working on a change that will perturb procfs' ctl interface to some
degree. In looking closer at procfs, it seems like it has been pretty well
broken for use as a debugging interface since at least 9.3 (the oldest system I
have handy). Is there any reason to maintain this interface at all? If anything,
it should perhaps be made into an alternate front end for ptrace() rather than
being entirely separate, but I'm not sure I see the value in that.
it to ptrace in r199805.
If nobody mentions a significant consumer, garbage-collecting it sounds good to me.
Eric
To clarify, I'm only targeting (for now) the string interface "ctl"
special file, not the ioctl interface on "mem" nor the other special
files (e.g. "regs"). Items in that last category seem to still have
legitimate (or at least convenient) uses, in that you can inspect a
process without needing to attach to it.

Here's what I plan to do:

https://reviews.freebsd.org/D9802

CC des@, procfs maintainer.

Eric
Dag-Erling Smørgrav
2017-02-26 15:06:51 UTC
Permalink
Post by Eric Badger
I started working on a change that will perturb procfs' ctl interface
to some degree. In looking closer at procfs, it seems like it has been
pretty well broken for use as a debugging interface since at least 9.3
(the oldest system I have handy). Is there any reason to maintain this
interface at all? If anything, it should perhaps be made into an
alternate front end for ptrace() rather than being entirely separate,
but I'm not sure I see the value in that.
If it's unused, go for it. It is an abomination. So is ptrace, but
we're stuck with it until someone comes up with something better. I
have tried and failed twice.

DES
--
Dag-Erling Smørgrav - ***@des.no
Loading...