[gPXE-devel] [PATCH] [jme] Adding JMicron Ethernet driver

[Guo-Fu Tseng]

On Mon, 31 May 2010 11:05:14 -0400, Marty Connor wrote
> On 5/31/10 9:08 AM, Guo-Fu Tseng wrote:
> > On Sat, 29 May 2010 16:27:55 +0100, Michael Brown wrote
> >> Yes.  Take a look at something like drivers/net/b44.c, and the 
> >> b44_rx_refill() function.
> 
> > In summary, it gPXE will never call poll depend on interrupt.
> > I belived it would help on extreme low memory status to modify
> > it to the behavior Michael Brown suggested. :)
> 
> The driver structure above is common to many gPXE device drivers and is
> recommended for the reasons that Michael mentioned and that you have
> verified.
> 
> One nice feature of the gPXE driver API is its simplicity.  Once you
> understand the reasons for some of its design decisions, those 
> decisions make more sense.
> 
> An exercise that I sometimes assign to GSoC students is to do a call
> tree by hand for a few gPXE network drivers.
> 
> Here are two such call trees done by a GSoC student from last year:
> 
>    http://etherboot.org/wiki/soc/2009/asdlkf/notes/rtl8169.c
>    http://etherboot.org/wiki/soc/2009/asdlkf/notes/3c90x.c
> 
> In particular, please note that in both cases a call to
> _refill_rx_ring() occurs in the open() routine and later via _poll().
> 
> While one could certainly do such a tree using a software tool ( for an
> example see: http://etherboot.org/wiki/doc/codeviz ), I find that doing
> them by hand is often more beneficial for new gPXE driver writers.
> 
> You have made excellent progress with the JMicron driver, and with this
> modification and associated testing we look forward to merging your 
> code into gPXE soon.
> 
> Many thanks for your fine work!
> 
> / Marty /
I see.
As I recently heard from Michael Brown: Consistency is a good thing!
And this behavior make sence.

I'll modify it to let it behaves like other drivers. :)

Guo-Fu Tseng