Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1227608pxb; Wed, 10 Feb 2021 03:25:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJzFn9E1+2k3dNXYxpPg1R/pXOEWpmxSCXJ06kAnj908ktOF5sIcNJ6Cj5HI84j8qbueVskZ X-Received: by 2002:a17:906:378d:: with SMTP id n13mr2407437ejc.386.1612956352929; Wed, 10 Feb 2021 03:25:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612956352; cv=none; d=google.com; s=arc-20160816; b=uahLwQdaSuyAx1eUsZUwrfomQtkm773b77wJBgEd8Q3S2QzsoPOCIqFmje7LeOKa2o iAz2f8xh9tVQakwiIMCi2ZlnphC/BX10rORJddzZ7S4e1ug6d0siaz6ZNK8IlBdBgp+j zkIQDDfDfcnXXRTQPjJkQ0eZZ2lngXavcjxM1OffHEBIELjUDJ97lhMiNAAWGsU9vT/6 KLlh1KWLxPdkKko9vBXQWxgqfTmtMLJ5vDEwfC7QMy0zWkP1H8kSRqmz5KVHJ4/QscqB dDkpuyEpLkCnMye+Gs/DLFtWGJ+ibbYBKvpLrKJsFgVO7w2CJcdlAjs/1oL86o7q21kZ wTqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=epWgg4N82pJMPYD/jE3CD4fOAmaG7v2CoJJp8n3DfUQ=; b=qgiVh06gRjlpQP9TYqPF0IVQyrb6zDzy4rO7khAC2SNhPGyHwlULrcwiBdPV/cBiWo eTXrk1fDEPQYn9Zx2k/05HBhH3uOQjbBdDklcy1E3NsBjfejVhPRdgtvSI0sUlgfb/fU K4GckXoVNesdxyWAn/laKL55eKLbSUyKkBkROF72NHl/QB3PxuWxz2I/dHNQKRPTi9/0 nGRV8xBkvx8c7EvodMKwvu2c+GorqxEdnKVQDOLxUn7suPiGe1L6IaOSs+MtzVHOvDux Py4ulK8NXlGUSfHIXK9Cni4ueYvx5pQ+tSRgBzz/flw1AyGor2l4KX49wJgbqI5HYUSc LDnA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r11si1135010eju.334.2021.02.10.03.25.29; Wed, 10 Feb 2021 03:25:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231784AbhBJLXs convert rfc822-to-8bit (ORCPT + 99 others); Wed, 10 Feb 2021 06:23:48 -0500 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:46601 "EHLO relay8-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230486AbhBJLPp (ORCPT ); Wed, 10 Feb 2021 06:15:45 -0500 X-Originating-IP: 90.2.4.167 Received: from xps13 (aputeaux-654-1-105-167.w90-2.abo.wanadoo.fr [90.2.4.167]) (Authenticated sender: miquel.raynal@bootlin.com) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 44AA11BF206; Wed, 10 Feb 2021 11:14:55 +0000 (UTC) Date: Wed, 10 Feb 2021 12:14:29 +0100 From: Miquel Raynal To: Miklos Szeredi Cc: Richard Weinberger , Vignesh Raghavendra , Boris Brezillon , Ron Minnich , sven , linux-kernel , linux-mtd , fuse-devel Subject: Re: [PATCH 0/8] MUSE: Userspace backed MTD v3 Message-ID: <20210210121429.4fb5ecf3@xps13> In-Reply-To: References: <20210124232007.21639-1-richard@nod.at> <1507208626.379155.1612906761549.JavaMail.zimbra@nod.at> Organization: Bootlin X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Miklos, Miklos Szeredi wrote on Wed, 10 Feb 2021 11:16:45 +0100: > On Tue, Feb 9, 2021 at 10:39 PM Richard Weinberger wrote: > > > > Miklos, > > > > ----- Ursprüngliche Mail ----- > > > If you look at fuse_do_ioctl() it does variable length input and > > > output at the same time. I guess you need something similar to that. > > > > I'm not sure whether I understand correctly. > > > > In MUSE one use case would be attaching two distinct (variable length) buffers to a > > single FUSE request, in both directions. > > If I read fuse_do_ioctl() correctly, it attaches always a single buffer per request > > but does multiple requests. > > Right. > > > In MUSE we cold go the same path and issue up to two requests. > > One for in-band and optionally a second one for the out-of-band data. > > Hmmm? > > Does in-band and OOB data need to be handled together? Short answer: yes. > If so, then two requests is not a good option. More detailed answer: There is a type of MTD device (NAND devices) which are composed, for each page, of X in-band bytes plus Y out-of-band metadata bytes. Accessing either the in-band data, or the out-of-band data, or both at the same time are all valid use cases. * Read operation details: From a hardware point of view, the out-of-band data is (almost) always retrieved when the in-band data is read because it contains meta-data used to correct eventual bitflips. In this case, if both areas are requested, it is highly non-efficient to do two requests, that's why the MTD core allows to do both at the same time. * Write operation details: Even worse, in the write case, you *must* write both at the same time. It is physically impossible to do one after the other (still with actual hardware, of course). That is why it is preferable that MUSE will be able to access both in a single request. Thanks, Miquèl