lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] ethernetif.c HANDLE error


From: Jonathan Larmour
Subject: Re: [lwip-devel] ethernetif.c HANDLE error
Date: Wed, 20 Feb 2008 18:38:46 +0000
User-agent: Thunderbird 1.5.0.12 (X11/20070530)

Pettinato, Jim wrote:
> True... But in all return paths from ip_output or ip_output_if (in
> tcp_out.c, etc.) that I can find (at least in 1.2.0), the return value
> is ignored.

Oh you're right with TCP it seems. I guess again, like ARP, there's an
asynchronous aspect with TCP, so what you're doing now has probably nothing
to do with the data being sent, particularly if it's something like a
retransmit timer. You couldn't guarantee an error return matched the data
you're sending, or for that matter that there even is an error return.

> And the same is true for UDP..

Maybe CVS has moved on there. I see the return value of
udp_sendto/udp_sendto_if checked in many places.

> Though udp_send() passes the
> error through to the caller, no calls from the stack code actually check
> the return value of udp_send(). (I assume applications are free to do
> so, however.)

Well indeed, udp_send() is itself an API function.


Jifl

> -----Original Message----- From:
> address@hidden
> [mailto:address@hidden On Behalf
> Of Jonathan Larmour Sent: Wednesday, February 20, 2008 12:05 PM To:
> lwip-devel Subject: Re: [lwip-devel] ethernetif.c HANDLE error
> 
> Pettinato, Jim wrote:
>> Jonathan, Piero:
>> 
>> It is my understanding that NO checking is done on the return value of
>>  low_level_output()... it looks to me like the return value is passed
>>  back up the call chain and then eventually ignored by tcp_output. I 
>> think you could return ERR_END_OF_THE_WORLD_IS_AT_HAND without effect.
>>  ;)
>> 
>> Am I mistaken perhaps?
> 
> There are some situations where that happens, for example if an ARP
> request caused a packet to be queued. But that seems legitimate since by
> the time you know there's an error, you're no longer in the right
> context.
> 
> But in the normal course of things I can see the following calling path
> for normal packets, each stage returning the error of the next: 
> ip_output -> ip_output_if -> netif->output which is etharp_output ->
> etharp_send_ip -> netif->linkoutput which is low_level_output.
> 
> Jifl


-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
Visit us @ Embedded World 2008, Nürnberg, Germany, 26-28 Feb:Stand 11-336
------["Si fractum non sit, noli id reficere"]------       Opinions==mine




reply via email to

[Prev in Thread] Current Thread [Next in Thread]