RFI: Ethernet driver ported from Linux
yar at comp.chem.msu.su
Thu Apr 19 07:56:16 UTC 2007
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.
More information about the freebsd-hackers