From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 19 08:49:35 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 519FF16A401 for ; Thu, 19 Apr 2007 08:49:35 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id 1474913C483 for ; Thu, 19 Apr 2007 08:49:34 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id CB6765C19; Thu, 19 Apr 2007 18:49:30 +1000 (EST) From: Alan Garfield To: Yar Tikhiy In-Reply-To: <20070419075604.GB60301@comp.chem.msu.su> References: <1176096815.4064.6.camel@hiro.auspc.com.au> <20070409.222300.-1350498722.imp@bsdimp.com> <20070417171622.GB95814@comp.chem.msu.su> <1176858032.4426.3.camel@hiro.auspc.com.au> <20070418074455.GD36635@comp.chem.msu.su> <1176948890.4175.50.camel@hiro.auspc.com.au> <20070419075604.GB60301@comp.chem.msu.su> Content-Type: text/plain Date: Thu, 19 Apr 2007 18:49:30 +1000 Message-Id: <1176972570.4177.1.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: RFI: Ethernet driver ported from Linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 08:49:35 -0000 On Thu, 2007-04-19 at 11:56 +0400, Yar Tikhiy wrote: > > > Apart from using fake MAC addresses, I don't think so. > > I don't understand the concept of a fake MAC address, sorry. > The classic Ethernet is a broadcast medium by design, so a very > primitive NIC can just receive all traffic and let the driver or > network stack decide if the host wants a particular frame. On > output, the network stack can usually put any source MAC address > into the frame -- it's true for the most of Ethernet network > interfaces. So MAC addresses are always "fake" in a sense, as > neither the hardware nor the medium design enforces them. You're right. I don't fully understand quite what's happening behind the scene it would seem. > If I understand your case right, the two processors, CPU and SP, > share a hardware buffer, in which they can put some data for the > other side, e.g., an Ethernet frame, and then prod the other side > with an interrupt. That fits the Ethernet model ideally, so there > should be no need for hacks unless the other side, the SP running > a special Linux, takes the whole thing wrong. Again, you're correct. The Linux driver does have a certain 'quality' to it, but otherwise it should work as you've said. Alan.