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

["Piotr Zięcik" <kosmo@semihalf.com>]

Wednesday 15 July 2009 17:05:44 Mike Frysinger napisa?(a):
> 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 ?

Yes. The patch allows read only first n bytes from packet. The rest is 
discaded, if buffer is too small. This behaviour is similar to Linux recv() 
function. I do not see why we have to force application to prepare 1,5kB 
buffer for received packets when for example it waits for ARP reply.

> probably better to add a new function with explicit semantics --
> eth_receive_partial() or something.

API uses simple open, read/write, close model. The eth_receive() function is 
used by API read() call on network device. I do not see space here another 
function.

-- 
Best regards,
Piotr Ziecik