-----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 <[EMAIL PROTECTED]> 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
