public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: akepner@sgi.com
Cc: grundler@parisc-linux.org, jbarnes@virtuousgeek.org, jes@sgi.com,
	randy.dunlap@oracle.com, rdreier@cisco.com,
	James.Bottomley@steeleye.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] infiniband: add "dmabarrier" argument to ib_umem_get()
Date: Tue, 02 Oct 2007 20:10:23 -0700 (PDT)	[thread overview]
Message-ID: <20071002.201023.85411373.davem@davemloft.net> (raw)
In-Reply-To: <20071003024906.GI26752@sgi.com>

From: akepner@sgi.com
Date: Tue, 2 Oct 2007 19:49:06 -0700

> 
> Pass a "dmabarrier" argument to ib_umem_get() and use the new 
> argument to control setting the DMA_BARRIER_ATTR attribute on 
> the memory that ib_umem_get() maps for DMA.
> 
> Signed-off-by: Arthur Kepner <akepner@sgi.com>

Acked-by: David S. Miller <davem@davemloft.net>

However I'm a little unhappy with how IA64 achieves this.

The last argument for dma_map_foo() is an enum not an int,
every platform other than IA64 properly defines the last
argument as "enum dma_data_direction".  It can take one
of several distinct values, it is not a mask.

This hijacking of the DMA direction argument is hokey at
best, and at worst is type bypassing which is going to
explode subtly for someone in the future and result in
a long painful debugging session.

Adding another argument could be painful to do this cleanly, but at
least with inline functions and macros it could just evaluate to
nothing on platforms that don't need it.

Either that, or we should turn the thing into an integer "flags"
across the board and audit every DMA mapping implementation so that it
can handle multiple bits being set.  But that's really ugly and
invites mistakes as I detailed above.


  reply	other threads:[~2007-10-03  3:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-03  2:49 [PATCH 4/5] infiniband: add "dmabarrier" argument to ib_umem_get() akepner
2007-10-03  3:10 ` David Miller [this message]
2007-10-03 17:51   ` akepner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071002.201023.85411373.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=James.Bottomley@steeleye.com \
    --cc=akepner@sgi.com \
    --cc=grundler@parisc-linux.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    --cc=rdreier@cisco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox