lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 07 Aug 2007 17:59:20 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	hadi@...erus.ca
Cc:	netdev@...r.kernel.org, shemminger@...ux-foundation.org,
	jgarzik@...ox.com, rusty@...tcorp.com.au
Subject: Re: [PATCH RFC]: napi_struct V5

From: jamal <hadi@...erus.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.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists