lkml.org 
[lkml]   [2011]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: getter PTRACE_GETSIGINFO should not modify anything [Re: [PATCH 11/11] ptrace: implement group stop notification for ptracer]

* Tejun Heo <tj@kernel.org> wrote:

> Hello,
>
> On Mon, May 16, 2011 at 02:17:11PM +0200, Jan Kratochvil wrote:
> > On Mon, 16 May 2011 10:43:50 +0200, Tejun Heo wrote:
> > > There's distinction between "broken" and "ugly". If it's ugly but
> > > functional, you don't need to "fix" it.
> >
> > The final goal is the user experience (such as the users of GDB), nothing else
> > matters. If it is so "ugly" the userland developers fail to use it the
> > project as a whole still broken.
>
> To me, it seems the breakage and mountain of workarounds come more from lack
> of proper documentation plus the current ptrace + job control + signal
> interaction which is really broken. For example, it seems nobody really
> understood how group stop and ptrace interacts and the different types of
> traps being used - strace(2) thought the same signal was being delivered
> twice.

Btw., i'd also like to offer the observation that even these days, running
brand-new Rawhide distribution with strace-4.5.20-2.fc15.x86_64 and a fresh
kernel, i *still* often see strace (or ptrace?) misbehavior like it
misprocessing Ctrl-C and leaving hung threads around which i have to clean up
manually ...

So if you could bring sanity in here i think we could live with a regression or
two, if the situation could be improved in the longer run - it's not like we
are protecting a stable bastion of robust functionality here ...

Thanks,

Ingo


\
 
 \ /
  Last update: 2011-05-16 15:03    [W:0.075 / U:10.884 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site