netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH][6/12][RFC/v1] Add IPoIB (IP-over-InfiniBand) driver
Date: Mon, 22 Nov 2004 07:14:34 -0800	[thread overview]
Message-ID: <52sm71ex0l.fsf@topspin.com> (raw)
In-Reply-To: 20041118200017.GA26976@infradead.org

OK, the "real" patches are coming now.  I just thought I would let you
know which of your comments I've acted on and which are still pending....

    Christoph> Please avoid -I statements for kernel code wherever
    Christoph> possible.  Just put the Infiniband Kernel Internal API
    Christoph> into $(TOPDIR)/include/infiniband/

This is no problem to do.  However, I'd like to see whether we can get
a consensus about where to put .h files.

    Christoph> This should read more like:

OK, Makefile is fixed.  I didn't realize foo-objs and foo-y worked the
same, thanks for teaching me.

    Christoph> Also ib_ipoib is a rather strange name, the double ib
    Christoph> doesn't make much sense.

True.  We use ib_xxx for all our module names, so ib_ipoib is
consistent, but changing to ipoib for the IPoIB driver is easy to do
if that's the right way to go.

    Christoph> Please don't refer to licenses at urls as they can
    Christoph> changed easily.  There's a toplevel COPYING file you
    Christoph> can reference, and if you want additional license bits
    Christoph> I'd suggets to keep them simple enough to be in the
    Christoph> file header.  Or better just stop the dual-licensing
    Christoph> sillyness - you'll copy code from other parts of the
    Christoph> kernel sooner or later that are GPL-only.

License is not fixed yet (needs to be cleared with all contributors).

    Christoph> Please make this and inline so you have proper
    Christoph> typechecking.  (And give it a less shouting name)

Done.

    Christoph> Please try to avoid global lists.  Looking at the code
    Christoph> this is used in two places:

    Christoph>  (1) the debugging pseudo fs (2) ipoib_remove_one

    Christoph> the latter would be much better served with a per
    Christoph> ib_device list anyway, and for (1) there must be a
    Christoph> better way than the global list either.

OK, I got rid of the global list, although the debug fs keeps a list
of devices added before the fs was mounted (static to the file with
debugging code).  I could get rid of that list by just creating the fs
superblock etc. at startup rather than waiting for a mount request,
but I didn't do that yet.  (I don't want to call kern_mount because
then the module use count gets bumped and the module can't be
unloaded)

    Christoph> Please don't use PCI dma calls in highlevel protocol
    Christoph> handlers.  At least use the dma_* calls or even better
    Christoph> restructure the code to avoid dma mapping outside the
    Christoph> HCA driver.

We can switch to dma_* (and in fact I see some reasons to do so).
However Greg KH suggested sticking with pci_* stuff until there's a
non-PCI device to deal with.

I'm pretty convinced that the DMA mapping needs to be exposed outside
the low-level driver.  Otherwise you're limiting what upper level code
can do with reusing DMA mappings, DMA pools, etc.

Thanks,
  Roland

  parent reply	other threads:[~2004-11-22 15:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200411181046.6Dz1IPtDKfpgSXN9@topspin.com>
2004-11-18 18:46 ` [PATCH][6/12][RFC/v1] Add IPoIB (IP-over-InfiniBand) driver Roland Dreier
2004-11-18 18:48   ` Roland Dreier
2004-11-18 20:00   ` Christoph Hellwig
2004-11-18 20:07     ` Roland Dreier
2004-11-22 15:14     ` Roland Dreier [this message]
2004-11-22 15:34       ` Christoph Hellwig
2004-11-22 15:37         ` Roland Dreier
2004-11-22 18:55         ` Roland Dreier
2004-11-22 20:04           ` Christoph Hellwig
2004-11-22 20:16             ` Roland Dreier

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=52sm71ex0l.fsf@topspin.com \
    --to=roland@topspin.com \
    --cc=hch@infradead.org \
    --cc=netdev@oss.sgi.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;
as well as URLs for NNTP newsgroup(s).