Re: remote kernel debugging over a network

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

Most of what I'm writing here has already been brought up elsewhere in
the thread; I'm collecting it here as a response to the specific
questions jgordeev asked.  Those who've read the rest of the thread
will probably find nothing new here.

>> My opinion, which is probably worth approximately what you paid for
>> it: custom protocol built directly atop Ethernet (ie, not IP-based).
> You are concerned about security?

Among other things.  Security is a concern, yes, but I'm also concerned
about code size and complexity in the kernel, especially debugging
code.  It's bad enough to be talking Ethernet at all; I'd be very
reluctant to either try to shoehorn another IP stack in there or use
the main IP stack.  Even a comparatively small and cut-back IP stack is
a relatively large and complex blob of code, much more than I would
like to have to deal with in a debugger interface.

>> It seems to me that, for this application, the downsides of TCP
>> outweigh the upsides.
> What downsides you have in mind?

Mostly covered in the previous paragraph: the (in)security of using
something routable and the code size/complexity and associated
reliability.

There is also the point that TCP includes a lot of logic designed to
support use cases which are pretty much totally irrelevant for this
purpose, so either you include even more (unnecessary for the task)
complexity or have a not-quite-TCP stack with all the inteoperability
headaches that implies.

> gdb does support serial lines.  I knew that pty can be used for
> emulating a terminal, but I was unsure whether it can be used for
> emulating a serial port.

Actually, a pty always emulates a serial port.  ptys are used when
emulating terminals only because a terminal has to be connected
somewhere to be useful, and the commonest case wants to connect the
(emualted) terminal to the host the emulator is running on, which is
exactly the kind of emulated serial port a pty provides.

> Hacking on gdb is not an option.  I will not do it,

Fair enough.

> and even if I did it, who would maintain it?

Two potential answers:

(1) gdb's upstream.  (While I don't know how NIH the gdb folks in
    particular are or aren't, in at least some cases upstream
    distributions have adopted changes.)

(2) The same person or persons who maintains the other code you're
    creating.

Of course, that's not to say either one would, or even should, happen.
And, given your lack of desire to do it to begin with, the question is
pretty much moot. :)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B