Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752161AbcDNS5G (ORCPT ); Thu, 14 Apr 2016 14:57:06 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:51972 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750956AbcDNS5E (ORCPT ); Thu, 14 Apr 2016 14:57:04 -0400 Date: Thu, 14 Apr 2016 12:56:59 -0600 From: Jason Gunthorpe To: Dennis Dalessandro Cc: Ira Weiny , 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: <20160414185659.GB12997@obsidianresearch.com> References: <20160414153727.6387.96381.stgit@scvm10.sc.intel.com> <20160414164550.GC6247@obsidianresearch.com> <20160414174830.GA11641@rhel.sc.intel.com> <20160414180540.GA12554@obsidianresearch.com> <20160414184200.GA10416@phlsvsds.ph.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160414184200.GA10416@phlsvsds.ph.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.160 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1111 Lines: 33 On Thu, Apr 14, 2016 at 02:42:01PM -0400, Dennis Dalessandro wrote: > >It certainly can't be years. > > Does fixing the current write()/writev() problem have any real > impact on how we proceed for the "1 char dev to rule them all" idea? We aren't going to take a bad uAPI into mainline. So how many times do you want to redo the userspace? I have no objection to the patch landing, just as long as it stays in staging until we have the uAPI discussion as a community. As for the 'one char device', I actually think it would be really simple. Add a new uverbs ioctl: int hfi1_fd = ioctl(uverbs_fd, RDMA_GET_DRIVER_OPS_FD, "psm2.intel.com"); ioctl(hfi1_fd, HFI1_IOCTL_ASSIGN_CTXT, ...); write(hfi1_fd, ...); At least that gives us far better options for discovery and versioning of this stuff than a driver-specific char device. [eg this would use anon_inode_getfile, like event fds, completion channels, etc] You guys need this the most, propose something already. * driver specific ioctls might be nicer, but people argue that is not performant enough for what you want... Unclear to me. Jason