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.
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox