From owner-freebsd-current@FreeBSD.ORG Fri Jul 9 14:48:25 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 055C016A4CF; Fri, 9 Jul 2004 14:48:24 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F35743D39; Fri, 9 Jul 2004 14:48:24 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i69EmOWg014706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2004 10:48:24 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i69EmJoh022148; Fri, 9 Jul 2004 10:48:19 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16622.45106.992924.734398@grasshopper.cs.duke.edu> Date: Fri, 9 Jul 2004 10:48:18 -0400 (EDT) To: Robert Watson In-Reply-To: References: <16622.41619.355522.170000@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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:48:25 -0000 Robert Watson writes: > In order to support really low level I/O, you basically need a polled > network API that doesn't really care where it's called from -- the > physical console and sio both fall into this category, but the current > ethernet stack pieces don't as well. It's not impossible to imagine > writing one, but the tricks that are pulled in the 4.x gdb-over-ethernet > kernel debugging won't work -- they call into the mbuf allocator and > assume it's "safe" -- in 4.x, it was risky, in 5.x you would get a panic > for trying to acquire locks in the debugger. 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.. Drew