RFI: Ethernet driver ported from Linux

Yar Tikhiy yar at comp.chem.msu.su
Fri Apr 20 23:24:45 UTC 2007


On Thu, Apr 19, 2007 at 12:34:16PM -0700, Julian Elischer wrote:
> 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?

Alan may be busy debugging the driver, so let me answer for him,
as he said my notion of the thing was correct.  Sun Fire 20z is a
more or less conventional amd64 machine but, besides the usual
components forming the main system (CPU, RAM, bus, etc) it contains
an additional small embedded-style computer (seems to be m68k based)
with the role of monitoring and managing the main system hardware
independently from the host OS, which can be overloaded with heavy
tasks, unstable, or unresponsive.  The small computer has its own
external Ethernet interface for remote management and also can
communicate with the main host OS via a small hardware buffer.  It
runs a custom Linux, and there's not much control over its properties.
The Linux is hard-coded to send and receive but Ethernet frames via
the buffer, so the main host OS has little choice there, too.

> >
> >>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 at freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"

-- 
Yar


More information about the freebsd-hackers mailing list