Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2913136ybi; Thu, 18 Jul 2019 17:08:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqyaUmkdrMWyd3sOfsBdNOuna+4tIm5ILHcZVv3NYieq8k/n7g7ILKhiQvmUv0wtIsSkrv/K X-Received: by 2002:a63:490a:: with SMTP id w10mr49709860pga.6.1563494936748; Thu, 18 Jul 2019 17:08:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563494936; cv=none; d=google.com; s=arc-20160816; b=n9ciw+h9TFKqdmcV/juws68Slak1Wc1yO79Yj6hH0iReMIHhf3N0e2o9oljWKzHoyT dpW6jb2vDdH7t9NvFIMmH2+rDEzmMGx7OwxcJcDalLJrGTudfC0tIzUfsoCKdqqOzOOV sqb2aurpgH9OeJPnRbOBF3gi8TocSgrabctl/iFM55vgHcfQBDfm9RHtFNqX5yPAzpqU cZ4p+8GHlshNflGCh/7EfFzXQSUBvg9vF6i7G34O6q87TzH4LYywp8FYIm3zfimDtSZi reB61nhYl5D/6zOjTqCH5ysCbUC0JEUvPXVE3hGAW+mzIqhWAkdVsSdMM4sqUvISmUx9 WsGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=W034AwSMWiF7xaHBFPaORQYyY1z06/sz7ZD+Qjg85zY=; b=SN054fvM9Fc7aKpL+5e5/rpLz7J52YDve9/vVQym/GDw/jkgzIlaIOBMlZwRgXJAds 8WChIZUwCZD7HOh3/2T0BePO73PzgA6U4ThPPhh4D42rgCumYy6hS+2ThaOJc5LnyJFE VbHpSOsJgQkwVafEc2aQPLUexyo0dOYxymhMDisfAD/NQj/r51shP/nDRolr8UAi7eC6 L+G+0lfEID6RNmQ6AqW5JBc3fJ1VFdb3JW0Wj266iiVWYWAwRsHy6BY1s6xOBeL/Wgdw ARcQaTR4cM4WwGnC1jyviRoV8NtA/V2YSvSWxkkSPlef/x8pQUSQOU7lPJbQRFNUjZYO S9dw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v185si1122600pgd.340.2019.07.18.17.08.41; Thu, 18 Jul 2019 17:08:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726251AbfGSAHH (ORCPT + 99 others); Thu, 18 Jul 2019 20:07:07 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:54484 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725992AbfGSAHH (ORCPT ); Thu, 18 Jul 2019 20:07:07 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92 #3 (Red Hat Linux)) id 1hoGQQ-0003bD-QA; Fri, 19 Jul 2019 00:07:02 +0000 Date: Fri, 19 Jul 2019 01:07:02 +0100 From: Al Viro To: Bjorn Andersson Cc: Benjamin LaHaise , linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] aio: Support read/write with non-iter file-ops Message-ID: <20190719000702.GW17978@ZenIV.linux.org.uk> References: <20190718231054.8175-1-bjorn.andersson@linaro.org> <20190718231751.GV17978@ZenIV.linux.org.uk> <20190718234352.GN30636@minitux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190718234352.GN30636@minitux> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 18, 2019 at 04:43:52PM -0700, Bjorn Andersson wrote: > On Thu 18 Jul 16:17 PDT 2019, Al Viro wrote: > > > On Thu, Jul 18, 2019 at 04:10:54PM -0700, Bjorn Andersson wrote: > > > Implement a wrapper for aio_read()/write() to allow async IO on files > > > not implementing the iter version of read/write, such as sysfs. This > > > mimics how readv/writev uses non-iter ops in do_loop_readv_writev(). > > > > IDGI. How would that IO manage to be async? And what's the point > > using aio in such situations in the first place? > > The point is that an application using aio to submit io operations on a > set of files, ... for no reason whatsoever, I take it? > can use the same mechanism to read/write files that > happens to be implemented by driver only implementing read/write (not > read_iter/write_iter) in the registered file_operations struct, such as > kernfs. ... except that it still has to support the kernels that don't have your patch, so the fallback in userland is *not* going away.