[Top][All Lists]
[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