From owner-freebsd-hackers Sat Feb 23 12:12:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 0BFAC37B402; Sat, 23 Feb 2002 12:12:49 -0800 (PST) Received: from pool0006.cvx40-bradley.dialup.earthlink.net ([216.244.42.6] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16eiXC-0007O4-00; Sat, 23 Feb 2002 12:12:43 -0800 Message-ID: <3C77F7AE.76EAAE24@mindspring.com> Date: Sat, 23 Feb 2002 12:12:30 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Bakul Shah , Michael Smith , "George V. Neville-Neil" , freebsd-hackers@freebsd.org Subject: Re: Kernel Debugging over the Ethernet? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Julian Elischer wrote: > > > The other issue with TCP is that you can set up specific > > > flows in the company firewall, and also permit SSLeay > > > based tunnel encapsulation from outside via an intermediate > > > machine. This isn't really required for off-site debugging, > > > but it gives another option. > > > > You are better off ssh-ing into a machine on the same net and > > running gdb there. This is really hard to do, when you are trying to debug a problem in the field in a situation that you can't repeat locally in your own lab, for whatever reason. 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. If I'm going to ssh into a local machine and debug from there, then I can use a serial cable. 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. > > 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. For the allocation, you *can* intercept it. What you do is allocate a chunk of mbufs when you allocate other fixed memory in machdep.c. It's pretty trivial. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message