Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux