On Monday 02 November 2009 10:08:00 Krzysztof Halasa wrote:
Mike Frysinger vapier@gentoo.org writes:
it's on purpose because it makes the code simpler -- no need to maintain state. drivers have to be able to handle halt() irregardless of init(). i dont see this being a problem for anyone.
Ok. Sure, that's not a problem for me, I just noted the README doesn't talk about this.
that's because the README covered whatever i could think of at the time, and i basically brain dumped what little i knew of the net framework. getting more people to read & question edge cases is good so those can be filled out.
(i already posted a patch for your first and last point)
- dev->recv() seems to be called recursively, for example while doing "dhcp" or "bootp" (ping is ok). dev->recv() in my driver calls NetReceive(), which in turn (without returning to the caller, i.e., dev->recv(), first) reinitializes the driver on error (calls dev->halt() and dev->init()). This makes a lot of mess in the driver, should it stay this way? Perhaps we should queue the received packets and process them on return from dev->recv()? Or maybe return all those packets together?
where exactly do you see that call path ? i dont see it anywhere ...
NetReceive() may call eth_send(), but that only expands into dev->send()
Let's look... The code does NetSetHandler(TftpHandler). I think NetReceive() calls (*packetHandler)() = TftpHandler and this one may call NetStartAgain().
but this doesnt call recv(), and NetStartAgain() changes the handler, so i still dont see recursion with the recv() function. but perhaps your definition of recursive is different from mine. recv() does not turn around and call recv(), but recv() may turn around and call other driver functions.
the tftp error behavior is to basically discard all pending packets, so in practice, it shouldnt be a big deal. it would probably be cleaner though if the packet handler returned an integer indicating errors that NetReceive() would pass up so that the driver recv knew to stop processing packets right away. Ben would have to comment here though as this is beyond the extent of my networking knowledge. -mike