All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.