From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22750 invoked by alias); 5 Jul 2007 15:41:56 -0000 Received: (qmail 22739 invoked by uid 22791); 5 Jul 2007 15:41:55 -0000 X-Spam-Check-By: sourceware.org Received: from nz-out-0506.google.com (HELO nz-out-0506.google.com) (64.233.162.237) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jul 2007 15:41:51 +0000 Received: by nz-out-0506.google.com with SMTP id f1so1744742nzc for ; Thu, 05 Jul 2007 08:41:50 -0700 (PDT) Received: by 10.115.59.4 with SMTP id m4mr8252339wak.1183650109035; Thu, 05 Jul 2007 08:41:49 -0700 (PDT) Received: by 10.115.51.15 with HTTP; Thu, 5 Jul 2007 08:41:48 -0700 (PDT) Message-ID: <68185b500707050841p90f7125sa7f10133064e90b8@mail.gmail.com> Date: Thu, 05 Jul 2007 15:41:00 -0000 From: "Michele Paselli" To: "Gary Thomas" Cc: ecos-discuss@ecos.sourceware.org In-Reply-To: <4688F3F9.4070306@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> <68185b500707020510l63e5f0e4sa4a07b198c44c91a@mail.gmail.com> <4688ED4E.8010903@mlbassoc.com> <68185b500707020537q606d4c1cs6e5dc5fe4ed09f1a@mail.gmail.com> <4688F3F9.4070306@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/msg00052.txt.bz2 Sorry but it took me some time to be able to give you an answer. No, raw sockets cannot solve my problem since what I should do is to get any packet that is sent to my eth controller (no matter the destination address or the protocol used) and forward it exactly as it is. I think that in this case the only thing I can do is interfacing my I/O driver directly to the low level eth driver, set my microcontroller in promiscuous mode and keep all the packets I get as they are. Anything wrong in that? Thanks anyway for your advices. Michele On 7/2/07, Gary Thomas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michele Paselli wrote: > > But we didn't agree that no raw socket was implemented in eCos? Then I > > don't understand how the "ping" tests can be based on SOCK_RAW. > > Have you tried it, or looked at the sources, or just assumed that > everything you read on this list is gospel? I don't know where > that line of reasoning came from (I hope I didn't say it first), > but I also didn't have time to refresh my memory about the stack > (after all, I did do that work more than 5 years ago...) > > Bottom line: use the source! > > One question which I've asked you multiple times (and not received > an answer) is whether RAW sockets solve your needs. > > > > > On 7/2/07, Gary Thomas wrote: > > Michele Paselli wrote: > >> 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. > > > > I don't understand what all the hoopla is about this. The BSD network > > stack provides for SOCK_RAW - why isn't this good enough? (Note: I > > know it works, at least at some level, because the 'ping' tests all > > work and they use RAW sockets!!) > > > > > >> 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). > > > > > > > >> > > - -- > - ------------------------------------------------------------ > Gary Thomas | Consulting for the > MLB Associates | Embedded world > - ------------------------------------------------------------ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFGiPP5maKbSsQGV8ARAh6JAJ9YY5SGwcUYN07+e3oAH7Eobe6E3ACeNlOD > zZytNmbqOJ2x3NX4Ds5YbqI= > =dIEe > -----END PGP SIGNATURE----- > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss