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