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

["Michele Paselli" <triguelon@gmail.com>]

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 <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).

-- 
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