[ECOS] Interfacing directly to the low level ethernet driver, how??

[Michele Paselli]

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.

Michele



On 7/2/07, Gary Thomas <gary@mlbassoc.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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 <gary@mlbassoc.com> 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
>
> iD8DBQFGiO1NmaKbSsQGV8ARAr69AJ9qvP00lzBgJkxnwRbYs6PlDgO4wACgnCz2
> 4i6Kzt/rJtc3knzw94AeGd8=
> =tyW6
> -----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