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

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

[Michele Paselli]

Hi ,

I'm about to develop a raw ethernet driver. After spending quite a lot 
of time reading the forum and analyzing the code I finally decide to 
implement a raw I/O API as suggested by Grant Edwards here:

http://www.cygwin.com/ml/ecos-discuss/2003-06/msg00017.html

The problem is that I'm finding quite a lot of difficulties in 
interfacing my I/O driver to the low level device driver of my eth 
controller. My idea is to use the netdevtab entry created in the .inl 
file and from there be able to access the eth_drv_sc structure and all 
the related functions. First problem, I saw that the existing network 
implementations (lwip and freebsd) before initializing the device the 
macros:
CYG_HAL_TABLE_BEGIN( __NETDEVTAB__, netdev );
CYG_HAL_TABLE_END( __NETDEVTAB_END__, netdev );
are called. Should I also use these macro? What is exactly their job? 
I guess they don't create an entry since for that the NETDEVTAB macro 
is used.
Second problem, in order to use the low level eth driver (packet 
CYGPKG_DEVS_ETH_HRDWR) I have to include also CYGPKG_IO_ETH_DRIVERS. 
When I compile everything with configtool I don't get any error but 
when I compile my test application this is what I get:

Building base.out
arm-elf-gcc -g -Ifmtc_install/include base.c -Lfmtc_install/lib -
Ttarget.ld -nostdlib -o base.out
fmtc_install/lib/libtarget.a(io_eth_eth_drv.o): In function 
`eth_drv_write':
/imecnl/software/common/ecos/opt/ecos/ecos-2.0.43
/packages/io/eth/v2_0_43/src/stand_alone/eth_drv.c:303: undefined 
reference to `start_console'
/imecnl/software/common/ecos/opt/ecos/ecos-2.0.43
/packages/io/eth/v2_0_43/src/stand_alone/eth_drv.c:307: undefined 
reference to `end_console'
fmtc_install/lib/libtarget.a(io_eth_eth_drv.o): In function 
`eth_drv_recv':
/imecnl/software/common/ecos/opt/ecos/ecos-2.0.43
/packages/io/eth/v2_0_43/src/stand_alone/eth_drv.c:493: undefined 
reference to `start_console'
/imecnl/software/common/ecos/opt/ecos/ecos-2.0.43
/packages/io/eth/v2_0_43/src/stand_alone/eth_drv.c:501: undefined 
reference to `end_console'
collect2: ld returned 1 exit status
make: *** [out] Error 1

I checked the various cdl files and I found out that the standalone 
eth i/o is automatically selected if I don't include any networking 
stack (but I don't want to, I want to get rid of TCP and all the upper 
layers).
What am I doing wrong? Am I approaching the problem in a wrong way?

Thanks a lot

Michele




_______________________________________________________
Naviga e telefona senza limiti con Tiscali     
Scopri le promozioni Tiscali Adsl: navighi e telefoni senza canone Telecom

http://abbonati.tiscali.it/adsl/


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

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

[Andrew Lunn]

On Wed, Jun 27, 2007 at 06:20:44PM +0200, Michele Paselli wrote:
> Hi ,
> 
> I'm about to develop a raw ethernet driver. After spending quite a lot 
> of time reading the forum and analyzing the code I finally decide to 
> implement a raw I/O API as suggested by Grant Edwards here:
> 
> http://www.cygwin.com/ml/ecos-discuss/2003-06/msg00017.html
> 
> The problem is that I'm finding quite a lot of difficulties in 
> interfacing my I/O driver to the low level device driver of my eth 
> controller. My idea is to use the netdevtab entry created in the .inl 
> file and from there be able to access the eth_drv_sc structure and all 
> the related functions. First problem, I saw that the existing network 
> implementations (lwip and freebsd) before initializing the device the 
> macros:
> CYG_HAL_TABLE_BEGIN( __NETDEVTAB__, netdev );
> CYG_HAL_TABLE_END( __NETDEVTAB_END__, netdev );
> are called. Should I also use these macro? What is exactly their job? 

These macros just create the beginning and end pointers to the list of
network devices. The Ethernet drivers then insert an entry into the
list for each network device.

In
packages/net/bsd_tcpip/current/src/ecos/support.c:cyg_net_init_devs()
there is code which iterates over this list initialising each device.

> Second problem, in order to use the low level eth driver (packet 
> CYGPKG_DEVS_ETH_HRDWR) I have to include also CYGPKG_IO_ETH_DRIVERS. 
> When I compile everything with configtool I don't get any error but 
> when I compile my test application this is what I get:
> 
> Building base.out
> arm-elf-gcc -g -Ifmtc_install/include base.c -Lfmtc_install/lib -
> Ttarget.ld -nostdlib -o base.out
> fmtc_install/lib/libtarget.a(io_eth_eth_drv.o): In function 
> `eth_drv_write':
> /imecnl/software/common/ecos/opt/ecos/ecos-2.0.43
> /packages/io/eth/v2_0_43/src/stand_alone/eth_drv.c:303: undefined 
> reference to `start_console'
> /imecnl/software/common/ecos/opt/ecos/ecos-2.0.43
> /packages/io/eth/v2_0_43/src/stand_alone/eth_drv.c:307: undefined 
> reference to `end_console'
> fmtc_install/lib/libtarget.a(io_eth_eth_drv.o): In function 
> `eth_drv_recv':
> /imecnl/software/common/ecos/opt/ecos/ecos-2.0.43
> /packages/io/eth/v2_0_43/src/stand_alone/eth_drv.c:493: undefined 
> reference to `start_console'
> /imecnl/software/common/ecos/opt/ecos/ecos-2.0.43
> /packages/io/eth/v2_0_43/src/stand_alone/eth_drv.c:501: undefined 
> reference to `end_console'
> collect2: ld returned 1 exit status
> make: *** [out] Error 1
> 
> I checked the various cdl files and I found out that the standalone 
> eth i/o is automatically selected if I don't include any networking 
> stack (but I don't want to, I want to get rid of TCP and all the upper 
> layers).

You probably need to modify the CDL in order to just have the packages
you need and configured how you want. In particular,
CYGPKG_IO_ETH_DRIVERS_NET probably wants 

active_if CYGPKG_NET || CYGPKG_RAW_ETH

          Andrew

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

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

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michele Paselli wrote:
> Hi ,
> 
> I'm about to develop a raw ethernet driver. After spending quite a lot 
> of time reading the forum and analyzing the code I finally decide to 
> implement a raw I/O API as suggested by Grant Edwards here:
> 
> http://www.cygwin.com/ml/ecos-discuss/2003-06/msg00017.html

What's the point of this?  Couldn't you solve your problem by
using RAW sockets?

The reason for asking is just to point out that your ethernet
"wire" will be pretty useless except for whatever raw traffic
you push across it.

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

iD8DBQFGguzumaKbSsQGV8ARAvteAJwLo2CbRE+ZiKt2QCzuFTKm7qktaQCgnVUg
EvW2AkdKd9yqyEY6+LzvbxQ=
=SC5P
-----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

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

[Michele Paselli]

Could you plase be more precise? I don't thing I got your question, I
thought that the version of FreeBSD on eCos didn't implement RAW
sockets. Or at least that's what I understood from previous threads
here. Am I wrong?

Thanks,

Michele



On 6/28/07, Gary Thomas <gary@mlbassoc.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michele Paselli wrote:
> > Hi ,
> >
> > I'm about to develop a raw ethernet driver. After spending quite a lot
> > of time reading the forum and analyzing the code I finally decide to
> > implement a raw I/O API as suggested by Grant Edwards here:
> >
> > http://www.cygwin.com/ml/ecos-discuss/2003-06/msg00017.html
>
> What's the point of this?  Couldn't you solve your problem by
> using RAW sockets?
>
> The reason for asking is just to point out that your ethernet
> "wire" will be pretty useless except for whatever raw traffic
> you push across it.
>
> - --
> - ------------------------------------------------------------
> 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
>
> iD8DBQFGguzumaKbSsQGV8ARAvteAJwLo2CbRE+ZiKt2QCzuFTKm7qktaQCgnVUg
> EvW2AkdKd9yqyEY6+LzvbxQ=
> =SC5P
> -----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

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

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michele Paselli wrote:
> Could you plase be more precise? I don't thing I got your question, I
> thought that the version of FreeBSD on eCos didn't implement RAW
> sockets. Or at least that's what I understood from previous threads
> here. Am I wrong?

Indeed, RAW sockets are not [currently] implemented.  My question was
what do you need that RAW sockets cannot provide?  I think it would be
a *much* simpler task to get RAW sockets working within the existing
stack than to write your own networking layer.

> 
> On 6/28/07, Gary Thomas <gary@mlbassoc.com> wrote:
> Michele Paselli wrote:
>> Hi ,
> 
>> I'm about to develop a raw ethernet driver. After spending quite a lot
>> of time reading the forum and analyzing the code I finally decide to
>> implement a raw I/O API as suggested by Grant Edwards here:
> 
>> http://www.cygwin.com/ml/ecos-discuss/2003-06/msg00017.html
> 
> What's the point of this?  Couldn't you solve your problem by
> using RAW sockets?
> 
> The reason for asking is just to point out that your ethernet
> "wire" will be pretty useless except for whatever raw traffic
> you push across it.
> 
>>

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

iD8DBQFGg7xRmaKbSsQGV8ARAixZAKCvC0Q8NUZ4is6Ij/x1i7LuPkwiWACgl2UX
WSej9b3NaFdEGNQkWVswKk0=
=b1KI
-----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

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

[Grant Edwards]

On 2007-06-28, Gary Thomas <gary@mlbassoc.com> wrote:

>>>> I'm about to develop a raw ethernet driver. After spending
>>>> quite a lot of time reading the forum and analyzing the code I
>>>> finally decide to implement a raw I/O API as suggested by
>>>> Grant Edwards here:
>>> 
>>>> http://www.cygwin.com/ml/ecos-discuss/2003-06/msg00017.html
>>> 
>>> What's the point of this?  Couldn't you solve your problem by
>>> using RAW sockets?

Yes, if RAW sockets were supported by eCos.

>>> The reason for asking is just to point out that your ethernet
>>> "wire" will be pretty useless except for whatever raw traffic
>>> you push across it.

No, the raw I/O API peacefully coexists with the normal network
stack API.  All network traffic that doesn't use the configured
proprietary Ethernet protocol number works the same as always.

>> Could you plase be more precise? I don't thing I got your
>> question, I thought that the version of FreeBSD on eCos didn't
>> implement RAW sockets. Or at least that's what I understood
>> from previous threads here. Am I wrong?
>
> Indeed, RAW sockets are not [currently] implemented.  My
> question was what do you need that RAW sockets cannot provide?
> I think it would be a *much* simpler task to get RAW sockets
> working within the existing stack than to write your own
> networking layer.

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.

-- 
Grant Edwards                   grante             Yow! Now that I have my
                                  at               "APPLE", I comprehend COST
                               visi.com            ACCOUNTING!!


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

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

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Grant Edwards wrote:
> On 2007-06-28, Gary Thomas <gary@mlbassoc.com> wrote:
> 
>>>>> I'm about to develop a raw ethernet driver. After spending
>>>>> quite a lot of time reading the forum and analyzing the code I
>>>>> finally decide to implement a raw I/O API as suggested by
>>>>> Grant Edwards here:
>>>>> http://www.cygwin.com/ml/ecos-discuss/2003-06/msg00017.html
>>>> What's the point of this?  Couldn't you solve your problem by
>>>> using RAW sockets?
> 
> Yes, if RAW sockets were supported by eCos.
> 
>>>> The reason for asking is just to point out that your ethernet
>>>> "wire" will be pretty useless except for whatever raw traffic
>>>> you push across it.
> 
> No, the raw I/O API peacefully coexists with the normal network
> stack API.  All network traffic that doesn't use the configured
> proprietary Ethernet protocol number works the same as always.
> 
>>> Could you plase be more precise? I don't thing I got your
>>> question, I thought that the version of FreeBSD on eCos didn't
>>> implement RAW sockets. Or at least that's what I understood
>>> from previous threads here. Am I wrong?
>> Indeed, RAW sockets are not [currently] implemented.  My
>> question was what do you need that RAW sockets cannot provide?
>> I think it would be a *much* simpler task to get RAW sockets
>> working within the existing stack than to write your own
>> networking layer.
> 
> 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.  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?

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.

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

iD8DBQFGg9J6maKbSsQGV8ARAjNQAKCdOYuaAJgDiNYe4MpIdN18Z0ue1ACZAYrl
LchvSjlG6a0qD5Brfvs+fv4=
=ws48
-----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

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

[Grant Edwards]

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

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

[Michele Paselli]

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

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

[Gary Thomas]

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

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

[Michele Paselli]

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.

Michele



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

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

[Gary Thomas]

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

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

[Grant Edwards]

On 2007-07-02, Michele Paselli <triguelon@gmail.com> 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.

RedBoot's network layer already supports raw packets, you might
not need to do anything.

> May I have problems with it if I don't synchronize packets?

RedBoot is single threaded, so there's no need for
synchronizing anything.

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



-- 
Grant Edwards                   grante             Yow! Thank god!! ... It's
                                  at               HENNY YOUNGMAN!!
                               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

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

[Michele Paselli]

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