[lkml]   [2010]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux-next: add utrace tree
On 01/26, Linus Torvalds wrote:
> The problem is that anything that is based on reparenting and signals is
> fundamentally a "one parent only" kind of interface. See?

Indeed. signals + do_wait() is the horrible model.

> So the reason I think using an fd is a good idea is _not_ because gdb
> already uses an fd internally, but because it gives you a "connection"
> between the debugger and debuggee that is not fundamentally limited to a
> single controller.
> (It doesn't have to be a file descriptor, of course, but could be any kind
> of other model that allows multiple connections.


But then we need something which represents this connection in kernel:
utrace_engine. Then we need something which allows multiple tracers to
cooperate. Just for example, one tracer wants to resume the tracee,
another tracer wants the tracee to be stopped. Utrace does this. And,
since we should preserve the current ptrace, the tracers should cooperate
with ptrace too.

IOW, this quickly leads to the new abstraction layer, I think. And of
course it is possible to implement this new model on top of utrace.

Yes, utrace itself comes with utrace_engine_ops vector to implement
"whatever you like", perhaps you dislike this part.


 \ /
  Last update: 2010-01-26 22:35    [W:0.246 / U:1.628 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site