On 07/30, Jan Kratochvil wrote: > > On Fri, 30 Jul 2010 14:57:55 +0200, Oleg Nesterov wrote: > > IIUK, the main goal is prototype the new generic API, > > As I thought there is an agreement the ptrace API has to stay.
Of course, ptrace can't go away. > We definitely need some serialized protocol as we need remote debugging with > multiple inferiors for cloud. Nobody argues. > I do not see why to create a new layer (your `new generic API') between kernel > and gdbserver-in-userland. Because gdb is not alone? I agree, it is probably most important. > > while the remote protocol (in my opinion) is obviously can't be considered > > as such. With this split it is possible to try to add some API and test it > > with or without gdb. Also, it is much more easy to play with the the > > protocol extensions (which I believe it needs) this way. > > If it is only a development tool for the in-kernel server then OK. Right now I do not know. > > It would be (I think) much easier to teach the real > > gdbserver and/or gdb to use this new API > > gdb linux-nat.c (=local gdb) should be deprecated. There is definitely a need > for remote target and actively maintaining two modes is not effective, we can > run gdbserver even during single-host debugging. OK, > We can port gdbserver to anything but I do not see the point. We should > probably move the threading support from gdbserver to gdb but there isn't much > left to do in userland gdbserver with properly designed kernel API. IOW, you think that it is better to shift gdbserver into kernel-space than port the existing one to the new API or write the new one in user space ? Oleg.
