* [ECOS] Interfacing directly to the low level ethernet driver, how?? @ 2007-06-27 21:10 Michele Paselli 2007-06-28 13:27 ` Andrew Lunn 2007-06-28 13:35 ` Gary Thomas 0 siblings, 2 replies; 14+ messages in thread From: Michele Paselli @ 2007-06-27 21:10 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] Interfacing directly to the low level ethernet driver, how?? 2007-06-27 21:10 [ECOS] Interfacing directly to the low level ethernet driver, how?? Michele Paselli @ 2007-06-28 13:27 ` Andrew Lunn 2007-06-28 13:35 ` Gary Thomas 1 sibling, 0 replies; 14+ messages in thread From: Andrew Lunn @ 2007-06-28 13:27 UTC (permalink / raw) To: Michele Paselli; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] Interfacing directly to the low level ethernet driver, how?? 2007-06-27 21:10 [ECOS] Interfacing directly to the low level ethernet driver, how?? Michele Paselli 2007-06-28 13:27 ` Andrew Lunn @ 2007-06-28 13:35 ` Gary Thomas 2007-06-28 13:49 ` Michele Paselli 1 sibling, 1 reply; 14+ messages in thread From: Gary Thomas @ 2007-06-28 13:35 UTC (permalink / raw) To: Michele Paselli; +Cc: ecos-discuss -----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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] Interfacing directly to the low level ethernet driver, how?? 2007-06-28 13:35 ` Gary Thomas @ 2007-06-28 13:49 ` Michele Paselli 2007-06-28 15:31 ` Gary Thomas 0 siblings, 1 reply; 14+ messages in thread From: Michele Paselli @ 2007-06-28 13:49 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] Interfacing directly to the low level ethernet driver, how?? 2007-06-28 13:49 ` Michele Paselli @ 2007-06-28 15:31 ` Gary Thomas 2007-06-28 15:34 ` [ECOS] " Grant Edwards 2007-07-02 12:10 ` [ECOS] " Michele Paselli 0 siblings, 2 replies; 14+ messages in thread From: Gary Thomas @ 2007-06-28 15:31 UTC (permalink / raw) To: Michele Paselli; +Cc: ecos-discuss -----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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [ECOS] Re: Interfacing directly to the low level ethernet driver, how?? 2007-06-28 15:31 ` Gary Thomas @ 2007-06-28 15:34 ` Grant Edwards 2007-06-28 15:48 ` Gary Thomas 2007-07-02 12:10 ` [ECOS] " Michele Paselli 1 sibling, 1 reply; 14+ messages in thread From: Grant Edwards @ 2007-06-28 15:34 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] Re: Interfacing directly to the low level ethernet driver, how?? 2007-06-28 15:34 ` [ECOS] " Grant Edwards @ 2007-06-28 15:48 ` Gary Thomas 2007-06-28 22:57 ` Grant Edwards 0 siblings, 1 reply; 14+ messages in thread From: Gary Thomas @ 2007-06-28 15:48 UTC (permalink / raw) To: Grant Edwards; +Cc: eCos Discussion -----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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [ECOS] Re: Interfacing directly to the low level ethernet driver, how?? 2007-06-28 15:48 ` Gary Thomas @ 2007-06-28 22:57 ` Grant Edwards 0 siblings, 0 replies; 14+ messages in thread From: Grant Edwards @ 2007-06-28 22:57 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] Interfacing directly to the low level ethernet driver, how?? 2007-06-28 15:31 ` Gary Thomas 2007-06-28 15:34 ` [ECOS] " Grant Edwards @ 2007-07-02 12:10 ` Michele Paselli 2007-07-02 12:19 ` Gary Thomas 2007-07-02 14:50 ` [ECOS] " Grant Edwards 1 sibling, 2 replies; 14+ messages in thread From: Michele Paselli @ 2007-07-02 12:10 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] Interfacing directly to the low level ethernet driver, how?? 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 14:50 ` [ECOS] " Grant Edwards 1 sibling, 1 reply; 14+ messages in thread From: Gary Thomas @ 2007-07-02 12:19 UTC (permalink / raw) To: Michele Paselli; +Cc: ecos-discuss -----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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] Interfacing directly to the low level ethernet driver, how?? 2007-07-02 12:19 ` Gary Thomas @ 2007-07-02 12:37 ` Michele Paselli 2007-07-02 12:48 ` Gary Thomas 0 siblings, 1 reply; 14+ messages in thread From: Michele Paselli @ 2007-07-02 12:37 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] Interfacing directly to the low level ethernet driver, how?? 2007-07-02 12:37 ` Michele Paselli @ 2007-07-02 12:48 ` Gary Thomas 2007-07-05 15:41 ` Michele Paselli 0 siblings, 1 reply; 14+ messages in thread From: Gary Thomas @ 2007-07-02 12:48 UTC (permalink / raw) To: Michele Paselli; +Cc: ecos-discuss -----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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ECOS] Interfacing directly to the low level ethernet driver, how?? 2007-07-02 12:48 ` Gary Thomas @ 2007-07-05 15:41 ` Michele Paselli 0 siblings, 0 replies; 14+ messages in thread From: Michele Paselli @ 2007-07-05 15:41 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [ECOS] Re: Interfacing directly to the low level ethernet driver, how?? 2007-07-02 12:10 ` [ECOS] " Michele Paselli 2007-07-02 12:19 ` Gary Thomas @ 2007-07-02 14:50 ` Grant Edwards 1 sibling, 0 replies; 14+ messages in thread From: Grant Edwards @ 2007-07-02 14:50 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2007-07-05 15:41 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-06-27 21:10 [ECOS] Interfacing directly to the low level ethernet driver, how?? 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 2007-07-02 14:50 ` [ECOS] " Grant Edwards
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).