On Sat, Oct 31, 2015 at 12:41 AM, <ira.weiny@xxxxxxxxx> wrote: > From: Mitko Haralanov <mitko.haralanov@xxxxxxxxx> > > Add mmu notify helper functions and TID caching function stubs in preparation > for the TID caching implementation. > > TID caching makes use of the MMU notifier to allow the driver to respond to the > user freeing memory which is allocated to the HFI. > > This patch implements the basic MMU notifier functions to insert, find and > remove buffer pages from memory based on the mmu_notifier being invoked. > > In addition it places stubs in place for the main entry points by follow on > code. > > Follow up patches will complete the implementation of the interaction with user > space and makes use of these functions. So this is an wholy orthogonal mechanism for memory registrations or de-registrations vs what's supported by the upstream RDMA stack to which this driver attempts to be a HW provider, right? Ira, Mike - why do that? 2. Greg - I read an earlier comment you made that a driver in staging need to be 1st and most **fixed** with patches such that the TODO items to get it out of staging are addressed. I see here every day long train of features going into this driver, should the focus need to be elsewhere, according to the staging guidelines? Or. > drivers/staging/rdma/hfi1/Kconfig | 1 + > drivers/staging/rdma/hfi1/Makefile | 2 +- > drivers/staging/rdma/hfi1/user_exp_rcv.c | 314 +++++++++++++++++++++++++++++++ > drivers/staging/rdma/hfi1/user_exp_rcv.h | 8 + > 4 files changed, 324 insertions(+), 1 deletion(-) _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
