On Mon, Mar 14, 2016 at 11:19:53PM +0200, Or Gerlitz wrote:
On Mon, Mar 14, 2016 at 2:01 PM, Dennis Dalessandro
<dennis.dalessandro@xxxxxxxxx> wrote:
On Mon, Mar 14, 2016 at 09:09:51AM +0200, Leon Romanovsky wrote:
Hi Doug,
I saw that you picked these patches and it is now in your github
repository. Since the original author probably missed my and Or's
questions, It
will be great if you can share with us your technical view on the topic.
In addition to my question regarding appropriate layer - IB/core. MM, I
see that
it can be natively implemented in user-space layer too.
The original author did not miss your questions. When I say "we" or "our"
you can be assured that includes the original author.
Just to make sure we're on the same page(...) submitting code to the
upstream kernel is not send-and-forget, authors should respond to
questions posed on their patches and this is very much not the case
how you act here.
Our position continues to be that this is best located in the hfi1 driver.
If something else comes along that can make use of the same/similar
functionality we can then move it to the core or elsewhere, once we have a
better understanding of the use cases and how best to generalize the code.
As I wrote your on this thread, you have all you need in user-space,
expect for mmu notifications for cache entries which were invalidated
by memunmaps, which indeed should originate from the kernel -- as such
the cache doesn't belong to the kernel at all. You didn't respond on
that, just ignored, and now again talking on the cache being in the
core, why?
I said "core or elsewhere". Elsewhere may well include user space. That is
just a different solution than what we have proposed. I agree that it is
certainly one alternative. I'd like to see what Doug's opinion on the matter
is.
Doug, As Dennis noted, you already picked ~300 patches for 4.6 / hfi1
driver from him. I don't see why picking this patch series there too
and not letting us to further discuss it out, thoughts?
Or.
I believe in taking an iterative approach to kernel development, if the code
doesn't cause problems I don't see any harm adding the series. If Doug
agrees with you and doesn't like this approach but is willing to let it
stand for now, I think the changes can be done in a subsequent release.
-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
