[En-Nut-Discussion] Beginning AVR and GCC
Berns J. Buenaobra
bbuenaobra at nip.upd.edu.ph
Wed Aug 13 04:30:12 CEST 2003
Hello:
Would any one in the group could reccommend a good website where and how to
begin with AVR and GCC? I have just made a purchase of a starter's kit from
a local supplier (and yes we do have them in the Philippines!)
www.ucpros.com
Thanks,
Berns B.
************************************
Bernardino J. Buenaobra
University Research Associate
National Institute of Physics
University of the Philippines
Diliman, Quezon City 1101
Philippines
Email: bbuenaobra at nip.upd.edu.ph
Tel/Voice: +632-434-4232
Fax/Data: +632-928-0296
Mobile: 0916-2550-056
URL: www.nip.upd.edu.ph/ipl
************************************
----- Original Message -----
From: <en-nut-discussion-request at egnite.de>
To: <en-nut-discussion at egnite.de>
Sent: Tuesday, August 12, 2003 3:00 AM
Subject: En-Nut-Discussion digest, Vol 1 #260 - 11 msgs
> Send En-Nut-Discussion mailing list submissions to
> en-nut-discussion at egnite.de
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.egnite.de/mailman/listinfo/en-nut-discussion
> or, via email, send a message with subject or body 'help' to
> en-nut-discussion-request at egnite.de
>
> You can reach the person managing the list at
> en-nut-discussion-admin at egnite.de
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of En-Nut-Discussion digest..."
>
>
> Today's Topics:
>
> 1. how to use NetRegisterInterrupt ? (Kim Madsen)
> 2. strtok_r conflicts (Theodore A. Roth)
> 3. linux build fixes and namespace clash work-arounds. (Theodore A.
Roth)
> 4. Re: strtok_r conflicts (peter.scandrett at transport.alstom.com)
> 5. Re: strtok_r conflicts (Theodore A. Roth)
> 6. ip filtering (Damian Slee)
> 7. Re: strtok_r conflicts (peter.scandrett at transport.alstom.com)
> 8. Re: strtok_r conflicts (Harald Kipp)
> 9. Re: ip filtering (Harald Kipp)
> 10. RE: ip filtering (Damian Slee)
> 11. RE: ip filtering (Harald Kipp)
>
> --__--__--
>
> Message: 1
> From: "Kim Madsen" <k_madsen at esenet.dk>
> To: <en-nut-discussion at egnite.de>
> Date: Mon, 11 Aug 2003 13:40:02 +0200
> Subject: [En-Nut-Discussion] how to use NetRegisterInterrupt ?
> Reply-To: en-nut-discussion at egnite.de
>
> Hi..
> Have any of you a code sample that the gcc avr will take without error
>
> void timer1(void* arg)
> {
>
> return;
> }
>
>
> NutRegisterInterrupt(14,&timer1,(void*)0);
>
> Kind regards
> Kim Madsen.
>
>
>
> --__--__--
>
> Message: 2
> Date: Mon, 11 Aug 2003 12:07:52 -0700 (PDT)
> From: "Theodore A. Roth" <troth at openavr.org>
> To: en-nut-discussion at egnite.de
> Subject: [En-Nut-Discussion] strtok_r conflicts
> Reply-To: en-nut-discussion at egnite.de
>
> Hi,
>
> I just tried to compile nutos from cvs and came across this error:
>
> make[2]: Entering directory
> `/home/roth/dev/ethernut/nut-cvs/app/httpd'
> avr-gcc -c -mmcu=atmega128 -Os -Wall -Wstrict-prototypes
> -Wa,-ahlms=httpserv.lst -I../../mod/include -I../../include
> httpserv.c -o httpserv.o
> In file included from httpserv.c:61:
> ../../include/strtok_r.h:11: error: conflicting types for `strtok_r'
> /home/roth/local/avr/avr/include/string.h:83: error: previous
> declaration of `strtok_r'
> make[2]: *** [httpserv.o] Error 1
> make[2]: Leaving directory `/home/roth/dev/ethernut/nut-cvs/app/httpd'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/roth/dev/ethernut/nut-cvs/app'
> make: *** [apps] Error 2
>
>
> My avr-libc is the current cvs version. The strtok_r prototype was add
> 2003/06/20:
>
>
http://savannah.nongnu.org/cgi-bin/viewcvs/avr-libc/avr-libc/include/string.h.diff?r1=1.4&r2=1.5
>
> I also noticed that the strtok_r decl in nutos is different than that
> in avr-libc and linux.
>
>
> Ted Roth
>
> --__--__--
>
> Message: 3
> Date: Mon, 11 Aug 2003 16:06:12 -0700 (PDT)
> From: "Theodore A. Roth" <troth at openavr.org>
> To: en-nut-discussion at egnite.de
> Subject: [En-Nut-Discussion] linux build fixes and namespace clash
work-arounds.
> Reply-To: en-nut-discussion at egnite.de
>
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware
tools.
> Send mail to mime at docserver.cac.washington.edu for more info.
>
> ---1463804408-847408033-1060643172=:18391
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Hi,
>
> The attached patch gets the latest cvs to build on linux and works
> around some namespace clashes with avr-libc.
>
> gcc-3.3.1, binutils-cvs-head, avr-libc-cvs-head
>
> Ted Roth
> ---1463804408-847408033-1060643172=:18391
> Content-Type: TEXT/PLAIN; charset=US-ASCII; name="nut-linux-fix.diff"
> Content-Transfer-Encoding: BASE64
> Content-ID: <Pine.LNX.4.53.0308111606120.18391 at knuth.amplepower.com>
> Content-Description:
> Content-Disposition: attachment; filename="nut-linux-fix.diff"
>
> MjAwMy0wOC0xMSAgVGhlb2RvcmUgQS4gUm90aCAgPHRyb3RoQG9wZW5hdnIu
> b3JnPg0KDQpGaXggY29tcGlsZSBvbiBsaW51eDoNCgkqIE1ha2VmaWxlIChh
> bGwpOiBBZGQgJChNQUtFX0NSVVJPTSkgY29tbWFuZC4NCgkqIGNvbmZpZ3Vy
> ZSAoVXNlckNvbmYubWspOiBGaXggQlVSTkZMQUdTIGFuZCBDUlVST00uDQoJ
> QWRkIG91dHB1dCBmb3IgTUFLRV9DUlVST00uDQoNCkZpeCBjbGFzaGVzIHdp
> dGggY3VycmVudCBhdnItbGliYzoNCgkqIGFwcC9odHRwZC9odHRwc2Vydi5j
> IChTaG93Rm9ybSk6IEF2b2lkIHN0cnRva19yIGNsYXNoIHdpdGggYXZyLWxp
> YmMuDQoJKiBjcnQvc3RydG9rX3IuYzogQXZvaWQgc3RydG9rX3IgY2xhc2gg
> d2l0aCBhdnItbGliYy4NCgkqIGluY2x1ZGUvc3RydG9rX3IuaDogQXZvaWQg
> c3RydG9rX3IgY2xhc2ggd2l0aCBhdnItbGliYy4NCgkqIG9zL251dGluaXQu
> YzogQXZvaWQgWFJBTUVORCBjbGFzaCB3aXRoIGF2ci1saWJjLg0KDQpJbmRl
> eDogTWFrZWZpbGUNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxl
> OiAvY3Zzcm9vdC9ldGhlcm51dC9udXQvTWFrZWZpbGUsdg0KcmV0cmlldmlu
> ZyByZXZpc2lvbiAxLjEuMS4xDQpkaWZmIC11IC1wIC1yMS4xLjEuMSBNYWtl
> ZmlsZQ0KLS0tIE1ha2VmaWxlCTkgTWF5IDIwMDMgMTQ6NDA6MjMgLTAwMDAJ
> MS4xLjEuMQ0KKysrIE1ha2VmaWxlCTExIEF1ZyAyMDAzIDIyOjQ4OjMxIC0w
> MDAwDQpAQCAtODcsNiArODcsNyBAQCBhbGw6DQogCSQoTUFLRSkgLUMgbmV0
> DQogCSQoTUFLRSkgLUMgcHJvDQogCSQoTUFLRSkgLUMgY3J0DQorCSQoTUFL
> RV9DUlVST00pDQogDQogaW5zdGFsbDoNCiAJJChNQUtFKSAtQyBvcyBpbnN0
> YWxsDQpJbmRleDogY29uZmlndXJlDQo9PT09PT09PT09PT09PT09PT09PT09
> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
> DQpSQ1MgZmlsZTogL2N2c3Jvb3QvZXRoZXJudXQvbnV0L2NvbmZpZ3VyZSx2
> DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMQ0KZGlmZiAtdSAtcCAtcjEuMSBj
> b25maWd1cmUNCi0tLSBjb25maWd1cmUJMTAgTWF5IDIwMDMgMTc6MDg6MTcg
> LTAwMDAJMS4xDQorKysgY29uZmlndXJlCTExIEF1ZyAyMDAzIDIyOjQ4OjMy
> IC0wMDAwDQpAQCAtNzcsOCArNzcsOSBAQCBkb25lDQogY2F0IDw8RU9GID4g
> VXNlckNvbmYubWsNCiBNQ1U9JERFVg0KIEJVUk49dWlzcA0KLUJVUk5GTEFH
> Uz0tZHByb2c9JFVJU1BfUFJPRyAtLWVyYXNlIC0tdXBsb2FkIC0tdmVyaWZ5
> IC1pZlwkKFRBUkcpDQotQ1JVUk9NID0gXCQodG9wX3NyY2RpcikvdG9vbHMv
> bGludXgvY3J1cm9tDQorQlVSTkZMQUdTPS1kcHJvZz0kVUlTUF9QUk9HIC0t
> ZXJhc2UgLS11cGxvYWQgLS12ZXJpZnkgLWlmPVwkKFRBUkcpDQorQ1JVUk9N
> ID0gXCQodG9wX3NyY2RpcikvdG9vbHMvY3J1cm9tL2NydXJvbQ0KK01BS0Vf
> Q1JVUk9NID0gXCQoTUFLRSkgLUMgXCQodG9wX3NyY2RpcikvdG9vbHMvY3J1
> cm9tDQogRU9GDQogDQogZWNobyAiWW91ciBzeXN0ZW0gaXMgbm93IGNvbmZp
> Z3VyZWQgdG8gYnVpbGQgZm9yICRERVYuIg0KSW5kZXg6IGFwcC9odHRwZC9o
> dHRwc2Vydi5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTog
> L2N2c3Jvb3QvZXRoZXJudXQvbnV0L2FwcC9odHRwZC9odHRwc2Vydi5jLHYN
> CnJldHJpZXZpbmcgcmV2aXNpb24gMS4yDQpkaWZmIC11IC1wIC1yMS4yIGh0
> dHBzZXJ2LmMNCi0tLSBhcHAvaHR0cGQvaHR0cHNlcnYuYwk3IEF1ZyAyMDAz
> IDA4OjI3OjU4IC0wMDAwCTEuMg0KKysrIGFwcC9odHRwZC9odHRwc2Vydi5j
> CTExIEF1ZyAyMDAzIDIyOjQ4OjM0IC0wMDAwDQpAQCAtMzgzLDggKzM4Myw4
> IEBAIGludCBTaG93Rm9ybShGSUxFICogc3RyZWFtLCBSRVFVRVNUICogcmUN
> CiAgICAgICAgIC8qIEV4dHJhY3QgMyBwYXJhbWV0ZXJzLiAqLw0KICAgICAg
> ICAgcXAgPSByZXEtPnJlcV9xdWVyeTsNCiAgICAgICAgIGZvciAoaSA9IDA7
> IGkgPCAzOyBpKyspIHsNCi0gICAgICAgICAgICBjW2ldID0gc3RydG9rX3Io
> JnFwLCAiPSIpOw0KLSAgICAgICAgICAgIHBbaV0gPSBzdHJ0b2tfcigmcXAs
> ICImIik7DQorICAgICAgICAgICAgY1tpXSA9IFBTX3N0cnRva19yKCZxcCwg
> Ij0iKTsNCisgICAgICAgICAgICBwW2ldID0gUFNfc3RydG9rX3IoJnFwLCAi
> JiIpOw0KICAgICAgICAgfQ0KIA0KICAgICAgICAgLyogU2VuZCB0aGUgcGFy
> YW1ldGVycyBiYWNrIHRvIHRoZSBjbGllbnQuICovDQpJbmRleDogY3J0L3N0
> cnRva19yLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAv
> Y3Zzcm9vdC9ldGhlcm51dC9udXQvY3J0L3N0cnRva19yLmMsdg0KcmV0cmll
> dmluZyByZXZpc2lvbiAxLjINCmRpZmYgLXUgLXAgLXIxLjIgc3RydG9rX3Iu
> Yw0KLS0tIGNydC9zdHJ0b2tfci5jCTIwIEp1bCAyMDAzIDE2OjAyOjMyIC0w
> MDAwCTEuMg0KKysrIGNydC9zdHJ0b2tfci5jCTExIEF1ZyAyMDAzIDIyOjQ4
> OjQ4IC0wMDAwDQpAQCAtMTYzLDcgKzE2Myw3IEBAIGNoYXIgKnN0cnNlcF9y
> KGNoYXIgKipwcF9zdHIsIGNvbnN0IGNoYXINCiAgKiBzdG9yZWQgaW4gKnN0
> ci4gVGhlIGZpcnN0IGNoYXJhY3RlciBub3QgYSBkZWxpbWl0ZXIgY2hhcmFj
> dGVyIGZyb20gdGhlIG9yaWdpbmFsIA0KICAqIHZhbHVlIG9mICpzdHIgaXMg
> cmV0dXJuZWQuDQogICovDQotY2hhciAqc3RydG9rX3IoY2hhciAqKnBwX3N0
> ciwgY29uc3QgY2hhciAqcF9kZWxpbSkNCitjaGFyICpQU19zdHJ0b2tfcihj
> aGFyICoqcHBfc3RyLCBjb25zdCBjaGFyICpwX2RlbGltKQ0KIHsNCiAgICAg
> cmVnaXN0ZXIgY29uc3QgY2hhciAqc3A7DQogICAgIGNoYXIgKnBfY2g7DQpJ
> bmRleDogaW5jbHVkZS9zdHJ0b2tfci5oDQo9PT09PT09PT09PT09PT09PT09
> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
> PT09DQpSQ1MgZmlsZTogL2N2c3Jvb3QvZXRoZXJudXQvbnV0L2luY2x1ZGUv
> c3RydG9rX3IuaCx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMS4xLjENCmRp
> ZmYgLXUgLXAgLXIxLjEuMS4xIHN0cnRva19yLmgNCi0tLSBpbmNsdWRlL3N0
> cnRva19yLmgJOSBNYXkgMjAwMyAxNDo0MTowMyAtMDAwMAkxLjEuMS4xDQor
> KysgaW5jbHVkZS9zdHJ0b2tfci5oCTExIEF1ZyAyMDAzIDIyOjQ4OjQ5IC0w
> MDAwDQpAQCAtOCw3ICs4LDcgQEANCiAvLyAgICAgICAgICAgICAgICAgICAg
> ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
> ICAgICAgICAgLy8NCiAvLy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
> LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
> Ly8NCiANCi1jaGFyICogc3RydG9rX3IoICBjaGFyICoqIHBwX3N0ciwgY29u
> c3QgY2hhciAqIHBfZGVsaW0gKTsNCitjaGFyICogUFNfc3RydG9rX3IoICBj
> aGFyICoqIHBwX3N0ciwgY29uc3QgY2hhciAqIHBfZGVsaW0gKTsNCiBjaGFy
> ICogc3Ryc2VwX3IoICBjaGFyICoqIHBwX3N0ciwgY29uc3QgY2hhciAqIHBf
> ZGVsaW0gKTsNCiBjaGFyICogc3Ryc2VwX3JzKCBjaGFyICoqIHBwX3N0ciwg
> Y29uc3QgY2hhciAqIHBfZGVsaW0sIGNoYXIgKiBwX3Rlcm0gKTsNCiANCklu
> ZGV4OiBvcy9udXRpbml0LmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09
> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJD
> UyBmaWxlOiAvY3Zzcm9vdC9ldGhlcm51dC9udXQvb3MvbnV0aW5pdC5jLHYN
> CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xLjEuMQ0KZGlmZiAtdSAtcCAtcjEu
> MS4xLjEgbnV0aW5pdC5jDQotLS0gb3MvbnV0aW5pdC5jCTkgTWF5IDIwMDMg
> MTQ6NDE6NTEgLTAwMDAJMS4xLjEuMQ0KKysrIG9zL251dGluaXQuYwkxMSBB
> dWcgMjAwMyAyMjo0ODo1MCAtMDAwMA0KQEAgLTU3LDYgKzU3LDcgQEANCiAN
> CiAjaW5jbHVkZSA8c3lzL2NvbmZvcy5oPg0KIA0KKyN1bmRlZiBYUkFNRU5E
> DQogI2RlZmluZSBYUkFNRU5EICgodm9sYXRpbGUgdV9jaGFyICopMHg3RkZG
> KQ0KIA0KICNpZmRlZiBfX0dOVUNfXw0K
>
> ---1463804408-847408033-1060643172=:18391--
>
> --__--__--
>
> Message: 4
> To: en-nut-discussion at egnite.de
> Subject: Re: [En-Nut-Discussion] strtok_r conflicts
> From: peter.scandrett at transport.alstom.com
> Date: Tue, 12 Aug 2003 11:45:48 +1000
> Reply-To: en-nut-discussion at egnite.de
>
> This is a multipart message in MIME format.
> --=_alternative 000946E6CA256D80_=
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all,
>
> Last night Ted Roth wrote
> I also noticed that the strtok_r decl
> in nutos is different than that in
> avr-libc and linux.
>
> When I initially wrote STRTOK_R, STRSEP_R and STRSEP_RS quite a few years
> ago I was unaware of the existing function prototypes. (The net was not as
> big as it is today.)
>
> This is my dilemma. Do I modify these functions to fit in with the
> existing function prototypes, or do I leave it alone? The prototypes would
> change from
> char * strtok_r( char ** pp_str, char * p_term );
> char * strsep_r( char ** pp_str, char * p_term );
> char * strsep_rs( char ** pp_str, char * p_term, char * p_sep );
> to
> char * strtok_r( char * p_str, char * p_term, char ** p_save );
> char * strsep_r( char * p_str, char * p_term, char ** p_save );
> char * strsep_rs( char * p_str, char * p_term, char ** p_save,
> char * p_sep );
>
> Changing it now would mean the minimum amount of code change to others as
> my version has been in circulation for less than two months.
>
> My feeling is my version should change to be the same as linux, qnx, mks,
> redhat, gnu, novell, etc.. However this may not be the best in the long
> term. The changes are not big.
>
> Your input, and especially Ted Roth's and Harald Kip's input, would be
> appreciated.
>
> Cheers,
> Peter Scandrett
> --=_alternative 000946E6CA256D80_=
> Content-Type: text/html; charset="us-ascii"
>
>
> <br><font size=2 face="sans-serif">Hi all,</font>
> <br>
> <br><font size=2 face="sans-serif">Last night Ted Roth wrote</font>
> <br><font size=2 face="Courier New"> I also
noticed that the strtok_r decl</font>
> <br><font size=2 face="Courier New"> in nutos
is different than that in</font>
> <br><font size=2 face="Courier New"> avr-libc
and linux.<br>
> </font>
> <br><font size=2 face="sans-serif">When I initially wrote STRTOK_R,
STRSEP_R and STRSEP_RS quite a few years ago I was unaware of the existing
function prototypes. (The net was not as big as it is today.)</font>
> <br>
> <br><font size=2 face="sans-serif">This is my dilemma. Do I modify these
functions to fit in with the existing function prototypes, or do I leave it
alone? The prototypes would change from</font>
> <br><font size=2 face="Courier New"> char *
strtok_r( char ** pp_str, char * p_term );<br>
> char * strsep_r( char ** pp_str, char *
p_term );</font>
> <br><font size=2 face="Courier New"> char *
strsep_rs( char ** pp_str, char * p_term, char * p_sep );</font>
> <br><font size=2 face="sans-serif">to</font>
> <br><font size=2 face="Courier New"> char *
strtok_r( char * p_str, char * p_term, char ** p_save );<br>
> char * strsep_r( char * p_str, char *
p_term, char ** p_save );<br>
> char * strsep_rs( char * p_str, char * p_term,
char ** p_save, char * p_sep );</font>
> <br>
> <br><font size=2 face="sans-serif">Changing it now would mean the minimum
amount of code change to others as my version has been in circulation for
less than two months.</font>
> <br>
> <br><font size=2 face="sans-serif">My feeling is my version should change
to be the same as linux, qnx, mks, redhat, gnu, novell, etc.. However this
may not be the best in the long term. The changes are not big.</font>
> <br>
> <br><font size=2 face="sans-serif">Your input, and especially Ted Roth's
and Harald Kip's input, would be appreciated.</font>
> <br>
> <br><font size=2 face="sans-serif">Cheers,<br>
> Peter Scandrett</font>
> --=_alternative 000946E6CA256D80_=--
>
> --__--__--
>
> Message: 5
> Date: Mon, 11 Aug 2003 22:21:24 -0700 (PDT)
> From: "Theodore A. Roth" <troth at openavr.org>
> To: en-nut-discussion at egnite.de
> Subject: Re: [En-Nut-Discussion] strtok_r conflicts
> Reply-To: en-nut-discussion at egnite.de
>
>
>
> On Tue, 12 Aug 2003 peter.scandrett at transport.alstom.com wrote:
>
> > Hi all,
> >
> > Last night Ted Roth wrote
> > I also noticed that the strtok_r decl
> > in nutos is different than that in
> > avr-libc and linux.
> >
> > When I initially wrote STRTOK_R, STRSEP_R and STRSEP_RS quite a few
years
> > ago I was unaware of the existing function prototypes. (The net was not
as
> > big as it is today.)
> >
> > This is my dilemma. Do I modify these functions to fit in with the
> > existing function prototypes, or do I leave it alone? The prototypes
would
> > change from
> > char * strtok_r( char ** pp_str, char * p_term );
> > char * strsep_r( char ** pp_str, char * p_term );
> > char * strsep_rs( char ** pp_str, char * p_term, char * p_sep );
> > to
> > char * strtok_r( char * p_str, char * p_term, char ** p_save );
> > char * strsep_r( char * p_str, char * p_term, char ** p_save );
> > char * strsep_rs( char * p_str, char * p_term, char ** p_save,
> > char * p_sep );
> >
> > Changing it now would mean the minimum amount of code change to others
as
> > my version has been in circulation for less than two months.
> >
> > My feeling is my version should change to be the same as linux, qnx,
mks,
> > redhat, gnu, novell, etc.. However this may not be the best in the long
> > term. The changes are not big.
>
> I'm curious why the change would "not be the best in the long term."
>
> I would think that sticking to the standard (I'm assuming that linux,
> et. al. adhere to the C standard) would be best in the long term.
>
> >
> > Your input, and especially Ted Roth's and Harald Kip's input, would be
> > appreciated.
>
> I have no idea about how wide-spread the use of your interface is, but
> within the nut source, the impact appears to be minimal. It's really
> Harald's call.
>
> Ted Roth
>
> --__--__--
>
> Message: 6
> Date: Tue, 12 Aug 2003 13:25:55 +0800
> From: "Damian Slee" <damian at commtech.com.au>
> To: <en-nut-discussion at egnite.de>
> Subject: [En-Nut-Discussion] ip filtering
> Reply-To: en-nut-discussion at egnite.de
>
> Hi,
> is it possible to add to the next version, a callback function to
filter/firewall incoming IP packets. If callback function == NULL, then
obviously doesn't get called.
>
> And possibly for TCP, UDP port firewalling as well.
>
> Regards,
>
> Damian
>
> --__--__--
>
> Message: 7
> To: en-nut-discussion at egnite.de
> Subject: Re: [En-Nut-Discussion] strtok_r conflicts
> From: peter.scandrett at transport.alstom.com
> Date: Tue, 12 Aug 2003 15:39:52 +1000
> Reply-To: en-nut-discussion at egnite.de
>
> This is a multipart message in MIME format.
> --=_alternative 001EB512CA256D80_=
> Content-Type: text/plain; charset="us-ascii"
>
> Ted,
>
> On Tue, 12 Aug 2003 troth at openavr.org wrote:
>
> > I would think that sticking to the standard (I'm assuming
> > that linux, et. al. adhere to the C standard) would be best
> > in the long term.
>
> > I have no idea about how wide-spread the use of your
> > interface is, but within the nut source, the impact
> > appears to be minimal.
>
> Technically, there is no ANSI C standard for these functions. What we have
> is a huge body of code (in fact everyone else) which is different to my
> versions in Nut/OS. My feeling is it should be changed. However I can't do
> it immediately as the computer it is on is on the other side of Sydney. I
> hope to be back there by the end of the week.
>
> Cheers,
> Peter Scandrett
>
> --=_alternative 001EB512CA256D80_=
> Content-Type: text/html; charset="us-ascii"
>
>
> <br><font size=2 face="sans-serif">Ted,</font>
> <br><font size=2 face="Courier New"><br>
> On Tue, 12 Aug 2003 troth at openavr.org wrote:<br>
> <br>
> > I would think that sticking to the standard (I'm assuming</font>
> <br><font size=2 face="Courier New">> that linux, et. al. adhere to the
C standard) would be best</font>
> <br><font size=2 face="Courier New">> in the long term.<br>
> <br>
> > I have no idea about how wide-spread the use of your</font>
> <br><font size=2 face="Courier New">> interface is, but within the nut
source, the impact</font>
> <br><font size=2 face="Courier New">> appears to be minimal.<br>
> </font>
> <br><font size=2 face="sans-serif">Technically, there is no ANSI C
standard for these functions. What we have is a huge body of code (in fact
everyone else) which is different to my versions in Nut/OS. My feeling is it
should be changed. However I can't do it immediately as the computer it is
on is on the other side of Sydney. I hope to be back there by the end of the
week.</font>
> <br>
> <br><font size=2 face="sans-serif">Cheers,<br>
> Peter Scandrett<br>
> </font>
> --=_alternative 001EB512CA256D80_=--
>
> --__--__--
>
> Message: 8
> Date: Tue, 12 Aug 2003 09:12:06 +0200
> To: en-nut-discussion at egnite.de
> From: Harald Kipp <harald.kipp at egnite.de>
> Subject: Re: [En-Nut-Discussion] strtok_r conflicts
> Reply-To: en-nut-discussion at egnite.de
>
>
> >
> >Technically, there is no ANSI C standard for these functions. What we
have
> >is a huge body of code (in fact everyone else) which is different to my
> >versions in Nut/OS. My feeling is it should be changed. However I can't
do
> >it immediately as the computer it is on is on the other side of Sydney. I
> >hope to be back there by the end of the week.
>
> The impact on changing the call is minimal.
> Go ahead, please. I'm just the maintainer. :-)
>
> Btw. I didn't realize that strtok_r has been implemented in
> the avrlibc. Is there any advantage using Peter's version?
> And if there is, why not add these enhancements into avrlibc.
>
> (Yes, Peter, I know that the avrlibc people ignored our previous
> request. But if they are just half as busy as I am...)
>
> Harald
>
>
> --__--__--
>
> Message: 9
> Date: Tue, 12 Aug 2003 09:21:54 +0200
> To: en-nut-discussion at egnite.de
> From: Harald Kipp <harald.kipp at egnite.de>
> Subject: Re: [En-Nut-Discussion] ip filtering
> Reply-To: en-nut-discussion at egnite.de
>
> Damian,
>
> Sounds interesting and easy to implement.
>
> Is there any such thing implemented on Linux or preferably BSD?
> I'd like to follow the way they did it.
>
> Regards,
>
> Harald
>
>
> --__--__--
>
> Message: 10
> Subject: RE: [En-Nut-Discussion] ip filtering
> Date: Tue, 12 Aug 2003 15:48:24 +0800
> From: "Damian Slee" <damian at commtech.com.au>
> To: <en-nut-discussion at egnite.de>
> Reply-To: en-nut-discussion at egnite.de
>
> don't know. Will see if I can find out.
>
> However ethernut is really only a single process, with no protection,
virtual address space (MMU) etc. So we can keep it real simple.
>
> -----Original Message-----
> From: Harald Kipp [mailto:harald.kipp at egnite.de]
> Sent: Tuesday, 12 August 2003 3:22 PM
> To: en-nut-discussion at egnite.de
> Subject: Re: [En-Nut-Discussion] ip filtering
>
>
> Damian,
>
> Sounds interesting and easy to implement.
>
> Is there any such thing implemented on Linux or preferably BSD?
> I'd like to follow the way they did it.
>
> Regards,
>
> Harald
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo/en-nut-discussion
>
> --__--__--
>
> Message: 11
> Date: Tue, 12 Aug 2003 10:01:09 +0200
> To: en-nut-discussion at egnite.de
> From: Harald Kipp <harald.kipp at egnite.de>
> Subject: RE: [En-Nut-Discussion] ip filtering
> Reply-To: en-nut-discussion at egnite.de
>
> I've been just asking in case you got any source. I can
> also try check BSD for filtering options.
>
> The callback itself is really simple. But some kind of API
> call is required to enable/disable it.
>
> As an alternative, the libnutnet may provide a default
> callback, which could be overridden by the application.
>
> Harald
>
>
>
> --__--__--
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo/en-nut-discussion
>
>
> End of En-Nut-Discussion Digest
>
More information about the En-Nut-Discussion
mailing list