From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 19 19:34:08 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 43D0116A407 for ; Thu, 19 Apr 2007 19:34:08 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA6D13C43E for ; Thu, 19 Apr 2007 19:34:08 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 19 Apr 2007 12:02:14 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id A59BA125AE6; Thu, 19 Apr 2007 12:34:07 -0700 (PDT) Message-ID: <4627C438.8000304@elischer.org> Date: Thu, 19 Apr 2007 12:34:16 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Alan Garfield 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> <1176972570.4177.1.camel@hiro.auspc.com.au> In-Reply-To: <1176972570.4177.1.camel@hiro.auspc.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yar Tikhiy , 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 19:34:08 -0000 Alan Garfield wrote: > 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. It sounds like this should be a "point-to-point" interface, and not an Ethernet interface.. If I understand what you are saying there is only ever communications between 2 entities. What is on the other side of this connection? > >> 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. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"