Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751668AbcDPP3m (ORCPT ); Sat, 16 Apr 2016 11:29:42 -0400 Received: from mga14.intel.com ([192.55.52.115]:6798 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751580AbcDPP3l (ORCPT ); Sat, 16 Apr 2016 11:29:41 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,492,1455004800"; d="scan'208";a="956349786" Date: Sat, 16 Apr 2016 11:29:35 -0400 From: Dennis Dalessandro To: Leon Romanovsky Cc: Ira Weiny , Christoph Hellwig , Jason Gunthorpe , dledford@redhat.com, linux-rdma@vger.kernel.org, linux-fsdevel@vger.kernel.org, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access Message-ID: <20160416152934.GA27403@phlsvsds.ph.intel.com> References: <20160414153727.6387.96381.stgit@scvm10.sc.intel.com> <20160414164550.GC6247@obsidianresearch.com> <20160414174830.GA11641@rhel.sc.intel.com> <20160415040126.GB10689@leon.nu> <20160415161754.GA21549@rhel> <20160415173035.GC10689@leon.nu> <20160415173401.GA10868@infradead.org> <20160415212328.GF10689@leon.nu> <20160415232800.GA32513@rhel> <20160416060940.GB6349@leon.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20160416060940.GB6349@leon.nu> User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2413 Lines: 50 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