Date: Sat, 21 Apr 2007 03:20:08 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Julian Elischer <julian@elischer.org> Cc: freebsd-hackers@freebsd.org, Alan Garfield <alan@fromorbit.com> Subject: Re: RFI: Ethernet driver ported from Linux Message-ID: <20070420232008.GB52136@comp.chem.msu.su> In-Reply-To: <4627C438.8000304@elischer.org> 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> <4627C438.8000304@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070420232008.GB52136>