public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Michele Paselli" <triguelon@gmail.com>
To: "Gary Thomas" <gary@mlbassoc.com>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Interfacing directly to the low level ethernet driver, how??
Date: Thu, 05 Jul 2007 15:41:00 -0000	[thread overview]
Message-ID: <68185b500707050841p90f7125sa7f10133064e90b8@mail.gmail.com> (raw)
In-Reply-To: <4688F3F9.4070306@mlbassoc.com>

Sorry but it took me some time to be able to give you an answer. No,
raw sockets cannot solve my problem since what I should do is to get
any packet that is sent to my eth controller (no matter the
destination address or the protocol used) and forward it exactly as it
is. I think that in this case the only thing I can do is interfacing
my I/O driver directly to the low level eth driver, set my
microcontroller in promiscuous mode and keep all the packets I get as
they are. Anything wrong in that?
Thanks anyway for your advices.

Michele



On 7/2/07, Gary Thomas <gary@mlbassoc.com> wrote:
> -----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-----
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  reply	other threads:[~2007-07-05 15:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-27 21:10 Michele Paselli
2007-06-28 13:27 ` Andrew Lunn
2007-06-28 13:35 ` Gary Thomas
2007-06-28 13:49   ` Michele Paselli
2007-06-28 15:31     ` Gary Thomas
2007-06-28 15:34       ` [ECOS] " Grant Edwards
2007-06-28 15:48         ` Gary Thomas
2007-06-28 22:57           ` Grant Edwards
2007-07-02 12:10       ` [ECOS] " Michele Paselli
2007-07-02 12:19         ` Gary Thomas
2007-07-02 12:37           ` Michele Paselli
2007-07-02 12:48             ` Gary Thomas
2007-07-05 15:41               ` Michele Paselli [this message]
2007-07-02 14:50         ` [ECOS] " Grant Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=68185b500707050841p90f7125sa7f10133064e90b8@mail.gmail.com \
    --to=triguelon@gmail.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=gary@mlbassoc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).