login
Search
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 fixAnton 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 sysfsArthur 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 userspaceDave 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 functionsHoang-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 userspaceJack Morgenstein (5):
IB/mlx4: Displa...
From: Roland Dreier <rdreier@cisco.com>
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.
-
On Thu, 11 Oct 2007 18:17:19 -0700 (PDT)
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).-
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
- infinibandand it all builds for me, but hey, I don't use half of it.
Oh, btw, one final note: because of just a *ton* ...
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
-
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
-
No, I meant more in the "who the hell is responsible for designing those
*files*" rather than who is responsible for the particular merge messI 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
-
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.
____
-
From: Linus Torvalds <torvalds@linux-foundation.org>
It all looks good from here.
-
> > 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.
-
From: Roland Dreier <rdreier@cisco.com>
Not the maintainer, I'm just saying you should gateway
your patches through him.
-
