Re: [PATCH] I/OAT: Add support for version 2 of ioatdma device

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Shannon Nelson <shannon.nelson@...>
Cc: <linux-kernel@...>, <dan.j.williams@...>
Date: Tuesday, October 23, 2007 - 3:56 pm

On Fri, 19 Oct 2007 00:20:25 -0700
Shannon Nelson <shannon.nelson@intel.com> wrote:


It's somewhat unusual to forward-declare an inline like this.  My version
of gcc does do the right thing with it, but for the sake of
conventionality, readability and cleanliness, please consider just moving
the implementations higher up the file sometime, thanks.



min_t is the preferred tool for this.


The noop_desc initialisation is unneeded and so too is the initialisation
of `desc', I suspect.

The compiler should avoid any additional code generation, but unneeded
initialisations like this can cause useful warnings to be suppressed and
they're a bit misleading to the reader of the code.



You can't do that!

GFP_ATOMIC allocations can and do fail under regular (albeit heavy) use. 
Code _must_ be able to recover from an allocation failure.  Taking out the
whole machine is not acceptable.

An exception to this is when the GFP_ATOMIC allocation is happening at
initial boot time (ie: in __init in code which cannot be loaded as a
module).



I assume that there's a spin_unlock_bh() somewhere..


Is it non-racy to test ->pending outside the lock?


The code is refreshingly free from usable comments.  A reader might wonder what
things like IOAT_DMA_DCA_ANY_CPU actually represent.  I can't work it out
from the bare C implementation.


grumble.  All these could be implemented as inlines.  Please only use
macros when the code cannot be implemented in C.

Reasons:

- we get typechecking even when CONFIG_YOUR_STUFF=n

- can still take the address of the functions (dubious)

- looks nicer


-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH] I/OAT: Add support for version 2 of ioatdma device, Shannon Nelson, (Fri Oct 19, 3:20 am)
Re: [PATCH] I/OAT: Add support for version 2 of ioatdma device, Andrew Morton, (Tue Oct 23, 3:56 pm)