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.
- 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().
the NetRxPackets[] are set up for you by default and are merely a convenience. you can use them or not, it doesnt really matter. after all, your driver is what calls NetReceive() and the first argument there is the buffer that you're receiving. none of the internal network code relies on these pointers.
I see. Thanks for your mail.