[GIT PULL] please pull infiniband.git for-linus

[GIT PULL] please pull infiniband.git for-linus

[Roland Dreier]

Linus, please pull from

    master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus

This tree is also available from kernel.org mirrors at:

    git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus

This will get the batch of changes queued up for the 2.6.24 merge
window (although I still have a few more things to merge later, once
Dave Miller's networking tree has landed too):

Ali Ayoub (1):
      IB/sa: Error handling thinko fix

Anton Blanchard (3):
      IB/fmr_pool: Clean up some error messages in fmr_pool.c
      IB/ehca: Make output clearer by removing some debug messages
      IB/ehca: Export module parameters in sysfs

Arthur Jones (4):
      IB/ipath: iba6110 rev4 GPIO counters support
      IB/ipath: Use counters in ipath_poll and cleanup interrupts in ipath_close
      IB/ipath: iba6110 rev4 no longer needs recv header overrun workaround
      IB/ipath: Indicate a couple of chip bugs to userspace

Dave Olson (5):
      IB/ipath: Verify host bus bandwidth to chip will not limit performance
      IB/ipath: Correctly describe workaround for TID write chip bug
      IB/ipath: Future proof eeprom checksum code (contents reading)
      IB/ipath: Fix QHT7040 serial number check
      IB/ipath: Minor fix to ordering of freeing and zeroing of tid pages.

Dotan Barak (2):
      mlx4_core: Use enum value GO_BIT_TIMEOUT_MSECS
      IPoIB/cm: Clean up initialization of QP attr in ipoib_cm_create_tx_qp()

Eli Cohen (3):
      IPoIB: Fix typo to end statement with ';' instead of ','
      IPoIB: Fix error path memory leak
      IB/mthca: Mark error paths as unlikely() in post_srq_recv functions

Hoang-Nam Nguyen (4):
      IB/ehca: Use remap_4k_pfn() to map firmware contexts to user space
      IB/ehca: Fix large page HW cap defines
      IB/ehca: Fix mem leak of firmware ctrlblock in ehca_create_srq()
      IB/ehca: Adjust 64-bit alignment of create QP response for userspace

Jack Morgenstein (5):
      IB/mlx4:  Display misc device information under /sys/class/infiniband/
      mlx4_core: Support ICM tables in coherent memory
      mlx4_core: Write MTTs from CPU instead with of WRITE_MTT FW command
      IB/mlx4: Implement FMRs
      mlx4_core: Increase max number of QPs per multicast group to 56

Joachim Fenkes (11):
      IB/ehca: Refactor hvcall tracing
      IB/ehca: Print return codes as signed decimal integers
      IB/ehca: ehca_gen_warn() should always print
      IB/ehca: Add check for max #SGE to create_qp()
      IB/ehca: Path migration support
      IB/ehca: Serialize MR alloc and MR free hvCalls
      IB/ehca: Replace get_paca()->paca_index by the more portable raw_smp_processor_id()
      IB/ehca: Bump version number and change its format
      IB/umem: Add hugetlb flag to struct ib_umem
      IB/ehca: Only use MR large pages for hugetlb regions
      IB/ehca: Return srq_attr->max_sge in ehca_query_srq()

Michael Albaugh (2):
      IB/ipath: Maintain active time on all chips
      IB/ipath: Better handling of unexpected GPIO interrupts

Michael S. Tsirkin (2):
      mlx4_core: Enable MSI-X by default
      IB/mthca: Enable MSI-X by default

Or Gerlitz (1):
      IPoIB: Allow setting policy to ignore multicast groups

Peter Oruba (1):
      IB/mthca: Use PCI-X/PCI-Express read control interfaces

Ralph Campbell (13):
      IB/core: Fix handling of multicast response failures
      IB/ipath: Performance optimization for CPU differences
      IB/ipath: Change UD to queue work requests like RC & UC
      IB/ipath: Remove unneeded code for ipathfs
      IB/ipath: UC RDMA WRITE with IMMEDIATE doesn't send the immediate
      IB/ipath: Remove redundant code
      IB/ipath: Generate flush CQE when QP is in error state
      IB/ipath: Implement IB_EVENT_QP_LAST_WQE_REACHED
      IB/ipath: Optimize completion queue entry insertion and polling
      IB/ipath: Add ability to set the LMC via the sysfs debugging interface
      IB/ipath: Remove duplicate copy of LMC
      IB/ipath: Fix IB_EVENT_PORT_ERR event
      IB/ipath: Remove redundant link state checks

Roland Dreier (18):
      IPoIB: Make sure no receives are handled when stopping device
      IB: find_first_zero_bit() takes unsigned pointer
      mlx4_core: Don't free special QPs in QP number bitmap
      IB/mlx4: Use __set_data_seg() in mlx4_ib_post_recv()
      IB/ehca: Include <linux/mutex.h> from ehca_classes.h
      IB/mlx4: Fix up SRQ limit_watermark endianness
      IB/iser: Remove unnecessary includes
      mlx4_core: Change capability decoding: SRC->XRC
      IB/umad: Add P_Key index support
      IB/umad: Fix bit ordering and 32-on-64 problems on big endian systems
      IB/uverbs: Make ib_uverbs_release_event_file() static
      mlx4_core: Reserve the correct number of MTT segments
      mlx4_core: Fix meaning of dev->caps.reserved_mtts
      IB/mthca: Increase max number of QPs per multicast group to 56
      IB/mthca: Use mmiowb() to avoid firmware commands getting jumbled up
      mlx4_core: Use mmiowb() to avoid firmware commands getting jumbled up
      IB/ehca: Fix clipping of device limits to INT_MAX
      mlx4_core: Fix section mismatches

Satyam Sharma (1):
      IB/ehca: Misc cpuinit section annotations and #ifdef cleanups

Sean Hefty (7):
      IPoIB: Specify Traffic Class with path record queries for QoS support
      IB/sa: Add new QoS fields to path record
      RDMA/cma: Add ability to specify type of service
      RDMA/ucma: Allow user space to set service type
      IB/srp: Add QoS support through service ID
      IB/cm: Modify interface to send MRAs in response to duplicate messages
      RDMA/cma: Queue IB CM MRAs to avoid unnecessary remote retries

Stefan Roscher (2):
      IB/ehca: Small QP userspace support
      IB/ehca: Support more than 4k QPs for userspace and kernelspace

Steve Wise (2):
      RDMA/cxgb3: Make the iw_cxgb3 module parameters writable
      RDMA/cma: Use neigh_event_send() to start neighbour discovery

 Documentation/infiniband/user_mad.txt          |   14 +
 drivers/infiniband/core/addr.c                 |    3 +-
 drivers/infiniband/core/cm.c                   |   51 ++--
 drivers/infiniband/core/cma.c                  |   46 +++-
 drivers/infiniband/core/device.c               |    4 +-
 drivers/infiniband/core/fmr_pool.c             |   22 +-
 drivers/infiniband/core/multicast.c            |    2 +-
 drivers/infiniband/core/sa_query.c             |   12 +-
 drivers/infiniband/core/ucma.c                 |   74 +++++-
 drivers/infiniband/core/umem.c                 |   20 ++-
 drivers/infiniband/core/user_mad.c             |  151 +++++++---
 drivers/infiniband/core/uverbs.h               |    1 -
 drivers/infiniband/core/uverbs_main.c          |   16 +-
 drivers/infiniband/hw/cxgb3/iwch_cm.c          |   16 +-
 drivers/infiniband/hw/ehca/ehca_classes.h      |   14 +-
 drivers/infiniband/hw/ehca/ehca_cq.c           |   23 +-
 drivers/infiniband/hw/ehca/ehca_hca.c          |   34 +-
 drivers/infiniband/hw/ehca/ehca_irq.c          |   33 +--
 drivers/infiniband/hw/ehca/ehca_main.c         |   52 ++--
 drivers/infiniband/hw/ehca/ehca_mcast.c        |    4 +-
 drivers/infiniband/hw/ehca/ehca_mrmw.c         |  102 ++++----
 drivers/infiniband/hw/ehca/ehca_qp.c           |  169 +++++++----
 drivers/infiniband/hw/ehca/ehca_reqs.c         |    2 +-
 drivers/infiniband/hw/ehca/ehca_sqp.c          |    2 +-
 drivers/infiniband/hw/ehca/ehca_tools.h        |   19 +-
 drivers/infiniband/hw/ehca/ehca_uverbs.c       |   46 ++--
 drivers/infiniband/hw/ehca/hcp_if.c            |  105 ++++---
 drivers/infiniband/hw/ehca/ipz_pt_fn.c         |    1 +
 drivers/infiniband/hw/ipath/ipath_common.h     |    4 +-
 drivers/infiniband/hw/ipath/ipath_cq.c         |   94 +++---
 drivers/infiniband/hw/ipath/ipath_diag.c       |   22 +-
 drivers/infiniband/hw/ipath/ipath_driver.c     |   93 ++++++-
 drivers/infiniband/hw/ipath/ipath_eeprom.c     |   10 +-
 drivers/infiniband/hw/ipath/ipath_file_ops.c   |   74 +++--
 drivers/infiniband/hw/ipath/ipath_fs.c         |  187 ------------
 drivers/infiniband/hw/ipath/ipath_iba6110.c    |   57 ++--
 drivers/infiniband/hw/ipath/ipath_iba6120.c    |   18 +-
 drivers/infiniband/hw/ipath/ipath_intr.c       |   64 +++--
 drivers/infiniband/hw/ipath/ipath_kernel.h     |   12 +-
 drivers/infiniband/hw/ipath/ipath_mad.c        |   53 ++--
 drivers/infiniband/hw/ipath/ipath_qp.c         |   31 ++-
 drivers/infiniband/hw/ipath/ipath_rc.c         |   73 ++++--
 drivers/infiniband/hw/ipath/ipath_ruc.c        |  308 +++++++-------------
 drivers/infiniband/hw/ipath/ipath_stats.c      |   17 +-
 drivers/infiniband/hw/ipath/ipath_sysfs.c      |   40 +++-
 drivers/infiniband/hw/ipath/ipath_uc.c         |   98 +++----
 drivers/infiniband/hw/ipath/ipath_ud.c         |  382 ++++++++----------------
 drivers/infiniband/hw/ipath/ipath_verbs.c      |  329 ++++++++++++++-------
 drivers/infiniband/hw/ipath/ipath_verbs.h      |   45 ++-
 drivers/infiniband/hw/mlx4/main.c              |   50 +++
 drivers/infiniband/hw/mlx4/mlx4_ib.h           |   16 +
 drivers/infiniband/hw/mlx4/mr.c                |  100 ++++++-
 drivers/infiniband/hw/mlx4/qp.c                |   14 +-
 drivers/infiniband/hw/mlx4/srq.c               |    2 +-
 drivers/infiniband/hw/mthca/mthca_cmd.c        |    6 +
 drivers/infiniband/hw/mthca/mthca_dev.h        |    2 +-
 drivers/infiniband/hw/mthca/mthca_main.c       |  110 ++++----
 drivers/infiniband/hw/mthca/mthca_srq.c        |    8 +-
 drivers/infiniband/ulp/ipoib/ipoib.h           |   24 ++-
 drivers/infiniband/ulp/ipoib/ipoib_cm.c        |   18 +-
 drivers/infiniband/ulp/ipoib/ipoib_ib.c        |    8 +
 drivers/infiniband/ulp/ipoib/ipoib_main.c      |   45 +++-
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c |   31 +--
 drivers/infiniband/ulp/ipoib/ipoib_verbs.c     |    2 +-
 drivers/infiniband/ulp/ipoib/ipoib_vlan.c      |    2 +
 drivers/infiniband/ulp/iser/iser_initiator.c   |    2 -
 drivers/infiniband/ulp/iser/iser_memory.c      |    2 -
 drivers/infiniband/ulp/iser/iser_verbs.c       |    1 -
 drivers/infiniband/ulp/srp/ib_srp.c            |    2 +
 drivers/net/mlx4/cmd.c                         |   11 +-
 drivers/net/mlx4/cq.c                          |    2 +-
 drivers/net/mlx4/eq.c                          |   13 +-
 drivers/net/mlx4/fw.c                          |    2 +-
 drivers/net/mlx4/icm.c                         |  134 +++++++--
 drivers/net/mlx4/icm.h                         |    9 +-
 drivers/net/mlx4/main.c                        |  130 +++++----
 drivers/net/mlx4/mcg.c                         |    2 +-
 drivers/net/mlx4/mlx4.h                        |   10 +-
 drivers/net/mlx4/mr.c                          |  242 +++++++++++++---
 drivers/net/mlx4/pd.c                          |    2 +-
 drivers/net/mlx4/qp.c                          |    5 +-
 drivers/net/mlx4/srq.c                         |    4 +-
 include/linux/mlx4/device.h                    |   27 ++
 include/rdma/ib_cm.h                           |    7 +-
 include/rdma/ib_sa.h                           |   11 +-
 include/rdma/ib_umem.h                         |    1 +
 include/rdma/ib_user_mad.h                     |   70 +++++-
 include/rdma/rdma_cm.h                         |   14 +
 include/rdma/rdma_user_cm.h                    |   18 ++
 89 files changed, 2498 insertions(+), 1710 deletions(-)

Re: [GIT PULL] please pull infiniband.git for-linus

[David Miller]

From: Roland Dreier <rdreier@cisco.com>
Date: Thu, 11 Oct 2007 18:08:52 -0700

> This will get the batch of changes queued up for the 2.6.24 merge
> window (although I still have a few more things to merge later, once
> Dave Miller's networking tree has landed too):

Roland are you absolutely sure this won't create merge conflicts with
my 8MB net-2.6 merge, inside of which there are many infiniband
driver changes?

I really wish you would submit your inifiniband work through normal
network driver channels, such as Jeff Garzik.  Jeff has been syncing
on almost a daily basis with me so that I wouldn't have to worry about
changes coming out of left field and adding additional merge issues
for an already difficult merge.

Even if you're confident there won't be merge issues, could you just
wait for the net-2.6 stuff to go in first?

Thanks.

Re: [ofa-general] Re: [GIT PULL] please pull infiniband.git for-linus

[Roland Dreier]

 > > This will get the batch of changes queued up for the 2.6.24 merge
 > > window (although I still have a few more things to merge later, once
 > > Dave Miller's networking tree has landed too):
 > 
 > Roland are you absolutely sure this won't create merge conflicts with
 > my 8MB net-2.6 merge, inside of which there are many infiniband
 > driver changes?

I'm not absolutely sure of anything but I have merged our two git
trees quite a few times during the 2.6.23 cycle and I have not seen
any conflicts.  Unless you've added some more IB changes very recently
I don't think there should be any problem.

 > I really wish you would submit your inifiniband work through normal
 > network driver channels, such as Jeff Garzik.  Jeff has been syncing
 > on almost a daily basis with me so that I wouldn't have to worry about
 > changes coming out of left field and adding additional merge issues
 > for an already difficult merge.

I'm not sure what you mean.  During the 2.6.23 cycle I've been sending
any patches that potentially could conflict with the net-2.6 tree to
you and Jeff so that you can merge them upstream via your tree.  Or do
you mean Jeff should become the maintainer of drivers/infiniband??

Can't you guys just keep the networking stuff contained in its little
box so it doesn't create maintenance problems for InfiniBand stuff?

 > Even if you're confident there won't be merge issues, could you just
 > wait for the net-2.6 stuff to go in first?

I don't mind waiting but I guess it's up to Linus really.

 - R.

Re: [ofa-general] Re: [GIT PULL] please pull infiniband.git for-linus

[David Miller]

From: Roland Dreier <rdreier@cisco.com>
Date: Thu, 11 Oct 2007 19:21:06 -0700

> I'm not sure what you mean.  During the 2.6.23 cycle I've been sending
> any patches that potentially could conflict with the net-2.6 tree to
> you and Jeff so that you can merge them upstream via your tree.  Or do
> you mean Jeff should become the maintainer of drivers/infiniband??

Not the maintainer, I'm just saying you should gateway
your patches through him.

Re: [ofa-general] Re: [GIT PULL] please pull infiniband.git for-linus

[Roland Dreier]

 > > I'm not sure what you mean.  During the 2.6.23 cycle I've been sending
 > > any patches that potentially could conflict with the net-2.6 tree to
 > > you and Jeff so that you can merge them upstream via your tree.  Or do
 > > you mean Jeff should become the maintainer of drivers/infiniband??
 > 
 > Not the maintainer, I'm just saying you should gateway
 > your patches through him.

What value do you see in that?  It just seems like it creates more
work for Jeff and gives no benefit over the current status quo.

 - R.

Re: [GIT PULL] please pull infiniband.git for-linus

[Linus Torvalds]

On Thu, 11 Oct 2007, David Miller wrote:
> 
> Even if you're confident there won't be merge issues, could you just
> wait for the net-2.6 stuff to go in first?

I pulled the net stuff first, and merged the IB stuff afterwards. No 
conflicts in IB, but there *were* conflicts with the networking pull for 
other reasons.

That horrid, horrid mess that is called include/linux/mod_devicetable.h 
and scripts/mod/file2alias.c must go at some point. The thing is 
unmaintainable. Different maintainers add their own structures to both, 
and functions to both, and it's just messy. That's not how maintainable 
and modularized code should be written.

Now it broke on sdio vs ssb, but there was actually a conflict earlier 
with the Kbuild merge (which I aborted for other reasons), so this file 
really is starting to be a problem.

The merge was fairly straightforward and stupid - it's not like the code 
added is *complicated*, but all those small functions and structrues are 
set up to be a maze of very similar lines, so the merge is actually much 
worse than it should be - because there is inherent similarity, some lines 
are automatically auto-merged, making the result just harder to visualize.

So I merged it all, and I don't expect any problems, but I'm hoping 
somebody is thinking about that mod_devicetable.h/file2alias.c mess.

I'm not entirely sure who to blame on that thing. I'm adding Greg to the 
Cc, on the assumption that blaming him is usually the right thing to do ;)

Oh, and obviously, the NAPI changes may well have resulted in a merge that 
had no actual *conflicts* in it, but whether the end result works or not 
(and whether any IB drivers need updating due to the NAPI changes), I 
cannot tell. I've pushed out my tree, so people who are competent or just 
morbidly curious should start looking at it: it's got the following things 
merged now:

 - x86 merge
 - mmc
 - v4l-dvb
 - blackfin
 - avr32
 - block layer updates
 - Jeff's dmi-const
 - Purdie's blacklight and led trees
 - ide
 - mips
 - net
 - infiniband

and it all builds for me, but hey, I don't use half of it.

Oh, btw, one final note: because of just a *ton* of renames, if you 
actually want git to do rename-detection for you and do automatic merges 
across those x86 renames, you should likely add

	[diff]
	        renamelimit=0

to your .gitconfig file. Otherwise, the rename detection heuristics may 
end up saying "I'm not going to even bother finding renames in that mess".

(That final note really shouldn't affect any normal users, but I thought 
I'd mention it in case somebody is going to want git to merge things 
across the x86 merge, and gets stuck not realizing why some versions of 
git might not notice the renames).

			Linus

Re: [GIT PULL] please pull infiniband.git for-linus

[David Miller]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 11 Oct 2007 19:58:04 -0700 (PDT)

> 
> 
> On Thu, 11 Oct 2007, David Miller wrote:
> > 
> > Even if you're confident there won't be merge issues, could you just
> > wait for the net-2.6 stuff to go in first?
> 
> I pulled the net stuff first, and merged the IB stuff afterwards. No 
> conflicts in IB, but there *were* conflicts with the networking pull for 
> other reasons.
> 
> That horrid, horrid mess that is called include/linux/mod_devicetable.h 
> and scripts/mod/file2alias.c must go at some point. The thing is 
> unmaintainable. Different maintainers add their own structures to both, 
> and functions to both, and it's just messy. That's not how maintainable 
> and modularized code should be written.
> 
> Now it broke on sdio vs ssb, but there was actually a conflict earlier 
> with the Kbuild merge (which I aborted for other reasons), so this file 
> really is starting to be a problem.
> 
> The merge was fairly straightforward and stupid - it's not like the code 
> added is *complicated*, but all those small functions and structrues are 
> set up to be a maze of very similar lines, so the merge is actually much 
> worse than it should be - because there is inherent similarity, some lines 
> are automatically auto-merged, making the result just harder to visualize.
> 
> So I merged it all, and I don't expect any problems, but I'm hoping 
> somebody is thinking about that mod_devicetable.h/file2alias.c mess.

It all looks good from here.

Re: [GIT PULL] please pull infiniband.git for-linus

[Greg KH]

On Thu, Oct 11, 2007 at 07:58:04PM -0700, Linus Torvalds wrote:
> 
> So I merged it all, and I don't expect any problems, but I'm hoping 
> somebody is thinking about that mod_devicetable.h/file2alias.c mess.
> 
> I'm not entirely sure who to blame on that thing. I'm adding Greg to the 
> Cc, on the assumption that blaming him is usually the right thing to do ;)

Hey, it wasn't me this time, I haven't even built my trees for you to
pull from and break everything yet :)

But yeah, splitting up the mod_devicetable.h/file2alias.c mess is a very
good idea, I'll see what I can come up with tomorrow.

thanks,

greg k-h

Re: [GIT PULL] please pull infiniband.git for-linus

[Linus Torvalds]

On Thu, 11 Oct 2007, Greg KH wrote:

> On Thu, Oct 11, 2007 at 07:58:04PM -0700, Linus Torvalds wrote:
> > 
> > So I merged it all, and I don't expect any problems, but I'm hoping 
> > somebody is thinking about that mod_devicetable.h/file2alias.c mess.
> > 
> > I'm not entirely sure who to blame on that thing. I'm adding Greg to the 
> > Cc, on the assumption that blaming him is usually the right thing to do ;)
> 
> Hey, it wasn't me this time, I haven't even built my trees for you to
> pull from and break everything yet :)

No, I meant more in the "who the hell is responsible for designing those 
*files*" rather than who is responsible for the particular merge mess 
that happened to involve them this time around.

> But yeah, splitting up the mod_devicetable.h/file2alias.c mess is a very
> good idea, I'll see what I can come up with tomorrow.

I don't think it's a huge issue, but I wanted to bring it up because these 
days we're normally so good with these kinds of things that it actually 
stood out a bit. I used to do these kinds of nasty merges all the time 
with init/main.c and the configuration files, until we split them up.

So I'm certainly perfectly able and used to doing them, it's just that I 
also think that we have generally learnt to do so much better.

In other words: no hurry or pressure, I just wanted to bring it up, since 
during the merge I got flashbacks to various "bad old times" that I had 
hoped we had mostly left behind.

Those files were originally designed/set up by Rusty. I could have blamed 
him, or perhaps Sam as a kbuild guy, but the reason I cc'd you is that I 
think this kind of smells like a "device model"ish thing...

Hmm?

		Linus

Redesigning file2alias for easy merging (bits of kbuild/kconfig)

[Oleg Verych]

* Thu, 11 Oct 2007 21:03:14 -0700 (PDT)

> On Thu, 11 Oct 2007, Greg KH wrote:
>
>> On Thu, Oct 11, 2007 at 07:58:04PM -0700, Linus Torvalds wrote:
>> > 
>> > So I merged it all, and I don't expect any problems, but I'm hoping 
>> > somebody is thinking about that mod_devicetable.h/file2alias.c mess.
>> > 
>> > I'm not entirely sure who to blame on that thing. I'm adding Greg to the 
>> > Cc, on the assumption that blaming him is usually the right thing to do ;)
>> 
>> Hey, it wasn't me this time, I haven't even built my trees for you to
>> pull from and break everything yet :)
>
> No, I meant more in the "who the hell is responsible for designing those 
> *files*" rather than who is responsible for the particular merge mess 
> that happened to involve them this time around.
>
>> But yeah, splitting up the mod_devicetable.h/file2alias.c mess is a very
>> good idea, I'll see what I can come up with tomorrow.
>
> I don't think it's a huge issue, but I wanted to bring it up because these 
> days we're normally so good with these kinds of things that it actually 
> stood out a bit. I used to do these kinds of nasty merges all the time 
> with init/main.c and the configuration files, until we split them up.
>
> So I'm certainly perfectly able and used to doing them, it's just that I 
> also think that we have generally learnt to do so much better.
>
> In other words: no hurry or pressure, I just wanted to bring it up, since 
> during the merge I got flashbacks to various "bad old times" that I had 
> hoped we had mostly left behind.
>
> Those files were originally designed/set up by Rusty. I could have blamed 
> him, or perhaps Sam as a kbuild guy, but the reason I cc'd you is that I 
> think this kind of smells like a "device model"ish thing...

If any amount of work will be done on (re)designing, i'd like to propose
documenting all that mod magic.

OK, it can be figured out from the code, and quick split+script_glue can
be "designed". But if goals and key points would be written in plain text
by person(s) who used to do and maintain it, that will be helpful.

Thanks.
____

Re: [GIT PULL] please pull infiniband.git for-linus

[Jeff Garzik]

Linus Torvalds wrote:
> Oh, and obviously, the NAPI changes may well have resulted in a merge that 
> had no actual *conflicts* in it, but whether the end result works or not 
> (and whether any IB drivers need updating due to the NAPI changes), I 
> cannot tell. I've pushed out my tree, so people who are competent or just 
> morbidly curious should start looking at it: it's got the following things 
> merged now:
> 
>  - x86 merge
>  - mmc
>  - v4l-dvb
>  - blackfin
>  - avr32
>  - block layer updates
>  - Jeff's dmi-const
>  - Purdie's blacklight and led trees
>  - ide
>  - mips
>  - net
>  - infiniband
> 
> and it all builds for me, but hey, I don't use half of it.


works here on intel x86-64, amd64, and 32-bit pentium4.

and without disk corruption, so I may now attend to the libata merge :)

	Jeff

Re: [GIT PULL] please pull infiniband.git for-linus

[Andrew Morton]

On Thu, 11 Oct 2007 18:17:19 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Roland Dreier <rdreier@cisco.com>
> Date: Thu, 11 Oct 2007 18:08:52 -0700
> 
> > This will get the batch of changes queued up for the 2.6.24 merge
> > window (although I still have a few more things to merge later, once
> > Dave Miller's networking tree has landed too):
> 
> Roland are you absolutely sure this won't create merge conflicts with
> my 8MB net-2.6 merge, inside of which there are many infiniband
> driver changes?

I'd have told him if there were any such problems.

There might of course be runtime problems, but I'm sure the infiniband
developers are testing -mm kernels so that any such problems will be
picked up beforehand (heh, I kill me).