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

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.

> > So, I'm gonna push back quite a bit unless it actually compromises
> > functionality or correctness.
> With your position "if it is workaroundable in userland let's make the new
> kernel API broken again" it no longer makes sense to comment on it. Yes,
> everything is workaroundable but that is usually not the goal of new APIs.

First of all, let's distinguish "broken" and "ugly" properly and
please keep in mind that what's broken is broken but beauty is in the
eyes of the beholder.

Secondly, I'm listening to your comments and will incorporate them, so
please don't give up so easily.

Thank you.


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