-----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 <gary@mlbassoc.com> 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 <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
iD8DBQFGiPP5maKbSsQGV8ARAh6JAJ9YY5SGwcUYN07+e3oAH7Eobe6E3ACeNlOD
zZytNmbqOJ2x3NX4Ds5YbqI=
=dIEe
-----END PGP SIGNATURE-----