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 _______________________________________________ gPXE-devel mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe-devel
