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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
