[U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.

[Ben Warren]

Mike Frysinger wrote:
> On Tuesday 14 July 2009 04:08:35 Piotr Ziecik wrote:
>   
>> When packets arrive on the interface that are larger than the buffer
>> being passed to U-Boot from a standalone application, then the
>> eth_receive() returns -1 and leaves the packet saved. The next call to
>> eth_receive() will find that same packet and can fail for the exact same
>> reason. A typical scenario is the loader doing ARP with a buffer of 66
>> bytes. The end result is that the ARP will fail and the loader panics.
>>
>> This patch fixes above problem by allowing partial packet read.
>>     
>
> seems like it could easily introduce incorrect behavior in existing 
> applications.  the code also sounds a bit risky ... your change would mean 
> people could read the leading part, but the rest is lost ?
>
> probably better to add a new function with explicit semantics -- 
> eth_receive_partial() or something.
> -mike
>   
I've read this whole thread, but this seems the most appropriate place 
to respond. 

I don't like changing the behavior of an existing call to truncation 
from an error, since who knows what will break.  Adding another call 
with different, documented behavior seems more appropriate.  I agree 
with Wolfgang that this really needs to be simple and personally don't 
see the burdens involved in allocating full MTU-sized buffers, but 
obviously can't envision all usage scenarios.

The talk of jumbo frames is currently moot, as the buffer size is fixed 
in U-boot @ 1518 (#define PKTSIZE 1518).  This should probably be 
configurable, but that's another matter.

regards,
Ben