[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100126210232.GF6567@basil.fritz.box>
Date: Tue, 26 Jan 2010 22:02:32 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andi Kleen <andi@...stfloor.org>, tromey@...hat.com,
Stephen Rothwell <sfr@...b.auug.org.au>,
Kyle Moffett <kyle@...fetthome.net>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Peter Zijlstra <peterz@...radead.org>,
Fr??d??ric Weisbecker <fweisbec@...il.com>,
Oleg Nesterov <oleg@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
"Frank Ch. Eigler" <fche@...hat.com>, linux-next@...r.kernel.org,
"H. Peter Anvin" <hpa@...or.com>, utrace-devel@...hat.com,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: linux-next: add utrace tree
> The problem is that anything that is based on reparenting and signals is
> fundamentally a "one parent only" kind of interface. See?
I was actually thinking about that before I wrote the email.
But when I did that i couldn't come up with a good scenario
where multiple debuggers actually make sense. In a sense
being a debugger is really a very "intimate" thing for process. Do you
really want to have multiple of them messing with each other?
If yes how would they know what to touch and what not?
The only thing I could think of was "user space virtualization"
(like old UML) together with a real debugger, but frankly
these solutions all seemed like big race conditions to me
anyways and should be better done in the kernel or below it,
so I have a hard time taking them seriously.
Can you think of any scenario where multiple debuggers
on a process make sense?
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists