This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Interfacing directly to the low level ethernet driver, how??
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Michele Paselli <triguelon at gmail dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Mon, 02 Jul 2007 06:19:26 -0600
- Subject: Re: [ECOS] Interfacing directly to the low level ethernet driver, how??
- References: <19489034.1182961244153.JavaMail.root@ps22> <4682ECF0.2010303@mlbassoc.com> <68185b500706280123td8b1f42ib855ab4d511ba68a@mail.gmail.com> <4683BC51.5030502@mlbassoc.com> <68185b500707020510l63e5f0e4sa4a07b198c44c91a@mail.gmail.com>
-----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