From owner-freebsd-current@FreeBSD.ORG Fri Jul 9 14:54:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BA0E16A4CE for ; Fri, 9 Jul 2004 14:54:58 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3EB043D49 for ; Fri, 9 Jul 2004 14:54:57 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i69EssWd036361; Fri, 9 Jul 2004 10:54:54 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i69EssUO036358; Fri, 9 Jul 2004 10:54:54 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 9 Jul 2004 10:54:54 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Andrew Gallatin In-Reply-To: <16622.45106.992924.734398@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.org Subject: Re: ethercons updated for -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2004 14:54:58 -0000 On Fri, 9 Jul 2004, Andrew Gallatin wrote: > For what its worth, Darwin has this for their KDP ethernet debugging. > To receive something, the debugger provides a buffer and specifies a > timeout. The driver keeps the same memory mapped for DMA, and just > copies into the provided void *buffer. There is also a polled transmit > routine, where the driver does not return until the outgoing packet has > been DMA'ed. In both cases, the driver is not allowed to allocate > memory, or do anything which can block. > > One thing that's always concerned me is how do they ensure the driver is > not in the middle of a "normal" transmit or recv when the debugger is > entered.. I have a lot of concerns about ensuring likely correctness of the model, including reentrancy, consistent hardware state, packets destined for the debugger wandering around the stack, etc. It strikes me that it's likely the network kernel debugging pieces work most of the time, and likely work especially well if you're not debugging the network stack :-). My guess would be that over time, Apple will start preferring (if they don't already) firewire debugging simply because it will become available earlier, work in more sticky situations, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research