2010-02-26 02:05:27

by Stephen Rothwell

[permalink] [raw]
Subject: linux-next: manual merge of the infiniband tree with the vfs tree

Hi all,

Today's linux-next merge of the infiniband tree got a conflict in
drivers/infiniband/core/uverbs_main.c between commit
ce916e2b935f8b3402da1457ff23b9f9f786c09b ("switch infiniband uverbs to
anon_inodes") from the vfs tree and commit
4169c4a9735d6434c9e39fa81ae5517e3afd4cd8 ("IB/uverbs: Use anon_inodes
instead of private infinibandeventfs") from the infiniband tree.

These two commits purport to do something similar. Someone should look
at them both and decide which one is right. For now I have used the
version from the vfs tree - with the addition of the part from the
infiniband tree version that selects ANON_INODES in the Kconfig file.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/


Attachments:
(No filename) (759.00 B)
(No filename) (198.00 B)
Download all attachments

2010-02-26 22:03:02

by Roland Dreier

[permalink] [raw]
Subject: Re: linux-next: manual merge of the infiniband tree with the vfs tree

> Today's linux-next merge of the infiniband tree got a conflict in
> drivers/infiniband/core/uverbs_main.c between commit
> ce916e2b935f8b3402da1457ff23b9f9f786c09b ("switch infiniband uverbs to
> anon_inodes") from the vfs tree and commit
> 4169c4a9735d6434c9e39fa81ae5517e3afd4cd8 ("IB/uverbs: Use anon_inodes
> instead of private infinibandeventfs") from the infiniband tree.
>
> These two commits purport to do something similar. Someone should look
> at them both and decide which one is right. For now I have used the
> version from the vfs tree - with the addition of the part from the
> infiniband tree version that selects ANON_INODES in the Kconfig file.

Huh, I didn't see that vfs commit and as far as I can tell it was never
posted anywhere. Which I guess is why we have linux-next :)

Anyway, both commits look essentially equivalent -- Al's moves the fd
allocation to callers, which is OK with me (a bit of duplicated code but
maybe a bit better layering of functions). I would like to see the
Kconfig part go in as part of the patch, although I guess it's not such
a terrible bit of breakage to fix up a bit after the fact. (Not a real
bisection killer)

Al, let me know what you want to do -- I can pick up your patch or drop
the patch from my tree, either way is fine.

- R.
--
Roland Dreier <[email protected]>
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html