From owner-freebsd-hackers Mon Feb 25 10:21:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from marlborough.cnchost.com (marlborough.concentric.net [207.155.248.14]) by hub.freebsd.org (Postfix) with ESMTP id AFBB237B402; Mon, 25 Feb 2002 10:21:18 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by marlborough.cnchost.com id NAA13901; Mon, 25 Feb 2002 13:21:09 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200202251821.NAA13901@marlborough.cnchost.com> To: Terry Lambert Cc: Julian Elischer , Michael Smith , "George V. Neville-Neil" , freebsd-hackers@freebsd.org Subject: Re: Kernel Debugging over the Ethernet? In-reply-to: Your message of "Sat, 23 Feb 2002 12:12:30 PST." <3C77F7AE.76EAAE24@mindspring.com> Date: Mon, 25 Feb 2002 10:21:08 -0800 From: Bakul Shah Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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