From mboxrd@z Thu Jan 1 00:00:00 1970 From: Piotr =?iso-8859-2?q?Zi=EAcik?= Date: Thu, 16 Jul 2009 11:51:59 +0200 Subject: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet. In-Reply-To: <200907151105.45474.vapier@gentoo.org> References: <1247558915-26591-1-git-send-email-kosmo@semihalf.com> <200907151105.45474.vapier@gentoo.org> Message-ID: <200907161151.59353.kosmo@semihalf.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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