Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Apr 2007 11:56:05 +0400
From:      Yar Tikhiy <yar@comp.chem.msu.su>
To:        Alan Garfield <alan@fromorbit.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: RFI: Ethernet driver ported from Linux
Message-ID:  <20070419075604.GB60301@comp.chem.msu.su>
In-Reply-To: <1176948890.4175.50.camel@hiro.auspc.com.au>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 19, 2007 at 12:14:50PM +1000, Alan Garfield wrote:
> On Wed, 2007-04-18 at 11:44 +0400, Yar Tikhiy wrote:
> >  
> > > Anyway, back to figuring out arp. UGH!
> > 
> > As a rule, an Ethernet driver needn't worry about ARP by itself
> > because ARP has own separate module in the network stack.  Does
> > your driver have a partucular reason to?
> 
> 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.

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.

-- 
Yar



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070419075604.GB60301>