All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <rdreier@cisco.com>
To: "Bryan O'Sullivan" <bos@pathscale.com>
Cc: akpm@osdl.org, greg@kroah.com, linux-kernel@vger.kernel.org,
	openib-general@openib.org
Subject: Re: [openib-general] Re: [PATCH 0 of 18] ipath driver - for inclusion in 2.6.17
Date: Fri, 24 Mar 2006 13:19:32 -0800	[thread overview]
Message-ID: <adaveu3pml7.fsf@cisco.com> (raw)
In-Reply-To: <1143227515.30626.43.camel@serpentine.pathscale.com> (Bryan O'Sullivan's message of "Fri, 24 Mar 2006 11:11:55 -0800")

    Bryan> Would your preference be to slap #ifdefs around those, or
    Bryan> to just require CONFIG_NET in Kconfig?  The core driver
    Bryan> should work fine without any kernel-level networking
    Bryan> support, so I suppose the former makes more sense.

Having #ifdef CONFIG_NET all over is definitely suboptimal.
Unfortunately it looks kind of hard to untangle your skb use from the
rest of the driver, so putting a dependency on NET might be the best bet.

    Bryan> That's going to be interesting to test, because I don't
    Bryan> have any ia64 hardware to even compile on.  I have tested
    Bryan> on x86_64 and powerpc, so this seems like an arch-level
    Bryan> header deficiency.  Any idea what to do about it?

How are you building on powerpc?  I don't see any way to turn on
CONFIG_PCI_MSI except on i386/x86_64 and ia64.

Anyway building an ia64 cross toolchain is easy with http://kegel.com/crosstool

I would just get rid of your atomic_clear_mask() and atomic_set_mask()
calls.  They're bogus because you're not even operating on an
atomic_t, and not many architectures implement them.  Just take a lock
if you need to modify the bitmap atomically.  A spinlock is cheaper
than two atomic operations (although I guess for a slow path, it hurts
in .text size).

    Bryan> I've been building with C=1 for months.  I'll see if I can
    Bryan> figure out why you're getting such different results.

It's probably because I use CF=-D__CHECK_ENDIAN__ too.

There are a few other things I don't think we've really closed on:

 - The whole duplicated SMA / ipath_verbs doesn't work without ib_mad loaded.

 - Andrew raised some questions about the special "pick a device for
   me" that I'm not sure we satisfied him on.  I don't find the
   /dev/ptmx argument that convincing, since I don't think /dev/ptmx
   is considered the best example of interface design.

 - It looks like ipath_copy.c is completely unused now that you're not
   including the ipath_ether driver.

 - R.

  parent reply	other threads:[~2006-03-24 21:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-24  4:41 [PATCH 0 of 18] ipath driver - for inclusion in 2.6.17 Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 1 of 18] ipath - core device driver Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 2 of 18] ipath - core driver header files Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 3 of 18] ipath - copy and send routines for sending an skb Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 4 of 18] ipath - support for HyperTransport devices Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 5 of 18] ipath - support for PCI Express devices Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 6 of 18] ipath - chip initialisation code Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 7 of 18] ipath - misc driver support code Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 8 of 18] ipath - sysfs and ipathfs support for core driver Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 9 of 18] ipath - char devices for diagnostics and lightweight subnet management Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 10 of 18] ipath - support for userspace apps using core driver Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 11 of 18] ipath - layering interfaces used by higher-level driver code Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 12 of 18] ipath - infiniband header files Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 13 of 18] ipath - infiniband UC and UD protocol support Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 14 of 18] ipath - infiniband RC " Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 15 of 18] ipath - misc infiniband code, part 1 Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 16 of 18] ipath - misc infiniband code, part 2 Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 17 of 18] ipath - infiniband verbs support Bryan O'Sullivan
2006-03-24  4:41 ` [PATCH 18 of 18] ipath - kbuild infrastructure Bryan O'Sullivan
2006-03-24 18:57 ` [PATCH 0 of 18] ipath driver - for inclusion in 2.6.17 Roland Dreier
2006-03-24 19:11   ` Bryan O'Sullivan
2006-03-24 20:57     ` Muli Ben-Yehuda
2006-03-24 21:19     ` Roland Dreier [this message]
2006-03-24 22:33       ` [openib-general] " Bryan O'Sullivan
2006-03-24 23:21         ` Roland Dreier
2006-03-25  0:03           ` Bryan O'Sullivan

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=adaveu3pml7.fsf@cisco.com \
    --to=rdreier@cisco.com \
    --cc=akpm@osdl.org \
    --cc=bos@pathscale.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openib-general@openib.org \
    /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.