On Sat, Apr 16, 2016 at 09:09:40AM +0300, Leon Romanovsky wrote:
On Fri, Apr 15, 2016 at 07:28:01PM -0400, Ira Weiny wrote:
On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote:
Do you have a technical reason that this patch series does not fix the
write/writev issue brought up by Al?
Sure, I truly believe that we can do common API in a months time-frame
and I want to be focused on one transition path only (write/read -> new
API) and not on two parallel paths (ioctl -> new API and write/read ->
new API) plus support of all these intermediate steps.
That doesn't say anything about how this patch doesn't address Al and
Linus's complaint, or raise a technical issue with the patch set.
These are two separate issues. I do not see a reason to try and make them
one, and use this to drive the "one-device to rule them all" idea. This
series converts the write() to ioctl() and fixes the problem we set to, as
promised. You don't like the API, that's fine. We'll discuss that on
linux-rdma, but no reason to hold this patch set while that happens.
The original request came after this driver was moved from staging to
RDMA stack, since the driver is still in staging, there is no need to
hurry up now.
There is no need to keep the driver in staging. This is not a driver that
has style problems or is not well tested. It is a driver that has been
heavily tested, performs well and has completed its staging TODO list. We
went ahead and added this write()/writev() fix before making the move
because Al and Linus wanted that issue addressed. For the record:
$ cat drivers/staging/rdma/hfi1/TODO
July, 2015
- Remove unneeded file entries in sysfs
- Remove software processing of IB protocol and place in library for use
by qib, ipath (if still present), hfi1, and eventually soft-roce
Both of those items are complete. The API issue was raised back when the
driver was submitted (almost a year ago), as you can see it did not make the
cut as a staging requirement. Whether you agree with the maintainer's
decision or not. I don't see how it's fair to try and add it again now.
As I mentioned let's discuss the uAPI stuff on linux-rdma. Have the web
meetings that you were mentioning and do whatever we need to in order to
improve the sub-system, but stop trying to tie our driver and moving out of
staging to this much larger issue.
Thanks
-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
