Re: [PATCH RFC]: napi_struct V5

[David Miller <davem@davemloft.net>]

From: jamal <hadi@cyberus.ca>
Date: Tue, 07 Aug 2007 08:52:35 -0400

> That doc is out of date on the split of work - it focusses mostly
> describing the original tulip which did not mix rx and tx in the
> napi_poll(). AFAIK, no driver does that today (although i really liked
> that scheme, there is a lot of fscked hardware out there that wont work
> well with that scheme). Where are the firemen when you need them? 

I am tempted to suggest we toss the document completely, for
two reasons:

1) It's geared towards conversions, whereas %99.9999 of the conversions
   that will ever happen, have happened.  Every single potential reader
   of this document is therefore writing new drivers with NAPI from the
   beginning.

2) Inaccurate documentation is often worse than no documentation.

It's not a bad thing to delete the document, and also we have a lot
of time until 2.6.24 finalizes with these changes and in that time
someone with the right incentive could write a fresh new NAPI
manual that represents reality.  Such a document could be added after
the merge window closes.

This also reminds me that we confuse people by having two driver
models for interrupt handling.  I've been reluctant to remove the
"optional" component of NAPI especially when it didn't handle
multi-queue properly (which basically made drivers for virtualized
devices impossible without using dummy devices for each queue).
But that is no longer true and there isn't any reason for a new
driver not to be NAPI from the beginning.