Date: Mon, 25 Feb 2002 10:21:08 -0800 From: Bakul Shah <bakul@bitblocks.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Julian Elischer <julian@elischer.org>, Michael Smith <msmith@freebsd.org>, "George V. Neville-Neil" <gnn@neville-neil.com>, freebsd-hackers@freebsd.org Subject: Re: Kernel Debugging over the Ethernet? Message-ID: <200202251821.NAA13901@marlborough.cnchost.com> In-Reply-To: Your message of "Sat, 23 Feb 2002 12:12:30 PST." <3C77F7AE.76EAAE24@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> The value of network debugging to me is not that I can > avoid buying a serial cable (big deal), it's that I can > do the debugging remotely. Agreed. > If I'm going to ssh into a local machine and debug from > there, then I can use a serial cable. The serial cable solution does not scale too well when you have many people simulteneously debugging multiple kernels. If you use 8-port serial cards on a machine and connect every other machine's serial console to it, that machine can become the bottleneck + even in a lab keeping track of all the serial cables etc. can be a pain. For us the ability to log in any test machine and debug any other test machine was very valuable. > The other issue is that, doing remote debugging from a > local machine, means I have to expose my source code on > that machine. If I tunnel in, insteaD, well, then I'm > not exposing the source code. There are other alternatives if this is an issue. For instance on a local machine you can put a little proxy or a tunnel endpoint. But see below. > > > For me the biggest reason for not using any IP was to > > > minimize any perturbation due to the debugger. The fact that > > > we have to steal mbufs is bad enough. > > > > I agree, especially when we will have locking etc for the mbuf queues. > > It's a pitty we can't intercept the mbuf allocate routines.. > > then we could keep a couple for ourself :-) > > IP is so you can make it through a cisco, etc. to another > routable segment. Oh I know that; but the cost of that convenience seems high. For us, with a lab full of test machines (used for simulating and testing various IP network clouds) a non-IP solution was preferable. But I can see that for other situations (such as debugging a machine colocated at your ISP, or debugging kernels in the field (ouch!)) our solution is far from ideal. Still, adding a separate tcp/ip stack just for debugging (as someone seemed to suggest) seems excessive. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202251821.NAA13901>