Frank Ch. Eigler wrote:
Shachar Shemesh <shac...@shemesh.biz> writes:
[...] The best way, as far as I can tell, to do that on Linux is to
use the PTRACE_GETSIGINFO command. [...] Unfortunately, utrace (at
least the version integrated into the Fedora Core 9 and Fedore 10
kernels) totally eliminated this system call. When calling ptrace
with PTRACE_GETSIGINFO I get back "Invalid argument". [...] I just
don't think breaking user space compatibility over the old
interface, broken though you might think it is, is justified.
The version of utrace I see lying around does not flat out disable
GETSIGINFO, but does return -EINVAL under some circumstances.
Version 0.16 of fakeroot-ng had a quite major changes so that it would
not rely on the FORK/VFORK detection for attaching to new processes, as
that would simply not work on Fedora Core 9. If you want something that
works on vanilla kernels but not on utrace, look no further than
fakeroot-ng version 0.15. I'm not particularly sorry about this change,
as it makes things less platform specific, and thus easier to port to
non-Linux platforms. This does not make me like utrace much more,
however... :-(
I
believe that any incompatibility with classical ptrace is unintended.
Would you be willing to submit a bugzilla.redhat.com report, with a
reproducing example, please?
The example I have right now (differentiating SIGTRAP from ptrace
events) I get to by modifying the fakeroot-ng source. This is quite a
far cry from a reduced small and compact test case, I admit.
I will try to construct a more compact example and post it to bugzilla.
No promises.
This is directed not so much against the utrace project as it is
against RedHat including it in production kernels.
The costs so far have been far outweighed by the benefits, FWIW.
I know this has been discussed before, but I, personally, have not been
able to understand what those benefits are. With no new user space APIs,
utrace only affects the kernel internals. If you are doing a lot of
kernel development or complicated debugging scenarios, then, sure, I can
see how utrace can be of help. For production kernels, however, I should
have expected that things would be more stable than that.
Renzo seems to think I should write a "fakeroot-ng kernel module". While
an interesting concept, I'm afraid that this will either totally violate
my design or will not gain me anything. Fakeroot-ng was built the way it
was built, to a large degree, to make it easier to port to new
platforms, and putting code that is even more platform dependent than it
is now goes against the design decisions, as far as I'm concerned.
Had userspace APIs already existed, then I might conceivably use them,
but asking the user to load a module just so they can emulate a root
environment from user space is, well, self contradicting. The whole
point of fakeroot-ng is that you do NOT need to be root in order to run it.
I'm not saying ptrace does not have deficiencies. It is a terrible
interface to do useful things with. All I'm saying is that, as long as
utrace is kernel only, comparing the two is comparing apples to oranges.
They are sort of the same, only extremely different.
I need to stress again. This rant is not against the utrace project, as
it sounds like an interesting and needed cleanup. This is against RedHat
including this (obviously not complete) change into their production
kernels.
- FChE
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
