From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7608 invoked by alias); 2 Jul 2007 12:10:38 -0000 Received: (qmail 7599 invoked by uid 22791); 2 Jul 2007 12:10:37 -0000 X-Spam-Check-By: sourceware.org Received: from wr-out-0506.google.com (HELO wr-out-0506.google.com) (64.233.184.231) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 02 Jul 2007 12:10:35 +0000 Received: by wr-out-0506.google.com with SMTP id i30so878630wra for ; Mon, 02 Jul 2007 05:10:33 -0700 (PDT) Received: by 10.114.110.1 with SMTP id i1mr5034375wac.1183378232171; Mon, 02 Jul 2007 05:10:32 -0700 (PDT) Received: by 10.115.51.15 with HTTP; Mon, 2 Jul 2007 05:10:32 -0700 (PDT) Message-ID: <68185b500707020510l63e5f0e4sa4a07b198c44c91a@mail.gmail.com> Date: Mon, 02 Jul 2007 12:10:00 -0000 From: "Michele Paselli" To: ecos-discuss@ecos.sourceware.org In-Reply-To: <4683BC51.5030502@mlbassoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <19489034.1182961244153.JavaMail.root@ps22> <4682ECF0.2010303@mlbassoc.com> <68185b500706280123td8b1f42ib855ab4d511ba68a@mail.gmail.com> <4683BC51.5030502@mlbassoc.com> Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Interfacing directly to the low level ethernet driver, how?? X-SW-Source: 2007-07/txt/msg00007.txt.bz2 Thanks guys, since in my specific application I don't need any other networking stacks I think I'll start implementing the I/O ethernet driver without any synchronization. My only concern is about Redboot, which also has a small networking layer. May I have problems with it if I don't synchronize packets? Of course I guess that then I'll not be able anymore to debug my system with ethernet but I can always do it with serial. Also, in my case I need to be extra fancy, because I have to receive ethernet packets in promiscouos mode, so even if the destination address in the packet is different from the one of the receiver one. Grant, I guess your driver will be built on top of the device specific one, so it will not be so different from mine. If your employer allows you, I would be grateful if you could contribute it, otherwise thanks anyway for your help. Michele On 2007-06-28, Gary Thomas wrote: >> It's a pretty thin layer -- it just allows you to queue up >> outbout packets with cyg_io_write() and read from a queue of >> inboung packets (with a specified protocol type) using >> cyg_io_read(). >> >> Using RAW sockets would be nice, but adding a little code to >> an in-house driver is logistically easier than adding raw >> socket support to an "off-the-shelf" network stack and then >> turning around and doing it all again a couple years later >> when the network stack changes. > > Your comments, while they make sense about eCos in general, > aren't helping. Sorry. I just wanted to point out that what I described is actually pretty simple. > I want to know why Michele thinks he needs to write his own > stack (that's what his questions were about). > > Do you have your cyg_io code? Can you contribute it? I'll check with my employer. All you do is register the Ethernet driver as a normal "cyg_io" style driver and add syncronization so that simultaneous "write" operations from the network stack and from cyg_io_write() don't trip over each other. If you want to be extra fancy, you can add a receive queue for the custom protocol packets. The code is all Ethernet device specific, so I'm not sure how much help it would be to contribute it. > As for the network stack changing - I don't see that happening > anytime soon. The last time was 5 years ago and there's not a > great impetus for change now. It makes sense to me to fix > things that are missing or broken, rather than inventing new > ways of doing things. I agree. If we were starting now, that's probably what I'd try first. But, 7 years ago we had no experience with either eCos or either of the BSD network stacks, so adding a few (OK, maybe 50-100) lines of code the the Ethernet driver seemed like the safest way to go, since it didn't require us to get up to speed on NetBSD stack internals, and there was no danger of having to maintain a forked network stack. It also allowed us to implement a very low overhead zero-copy mechanism for raw ethernet I/O in a product where network stack overhead was by far the most significant bottleneck (I also spent several weeks writing and tweaking an assembly-language IP checksum routine). -- Grant Edwards grante Yow! ! Up ahead! It's a at DONUT HUT!! visi.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss