Where has GETSIGINFO gone?

[Shachar Shemesh]

Frank Ch. Eigler wrote:
> Shachar Shemesh <shachar at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/utrace-devel/attachments/20090712/0690a758/attachment.htm>