From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01B07C433E0 for ; Wed, 10 Feb 2021 11:16:07 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9F30764D99 for ; Wed, 10 Feb 2021 11:16:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F30764D99 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=i5fVM7dgSchP2FMQFrACCH65fjAuYso3kWQtzq+rh2g=; b=R1UdRgq8OPumuQCcylMZrlwJq pFz2vgmV1xVxKvLsr6aFDrIaRr0+5frgDQZB4Nv40H/CjaUYFfet9FL8BnKyZiGhVTHIi12Ug59js 0i/S6OHFpuxc4C7ruiHd0RM5RQzJ+l6qk2Rugu81jealhUdc3m3lWapK3WX66qNCuCleo2ZXhS+nU osMXrEAWLZp7aXeXaRUoEdAnwN1tFriyYc8R2hpwU4/1vloKjkVcyIxWGWMvx5Ags49fhMNLy/qpd 9HGm1nxJimvF3epSJMFYaJGzG76+WHAB5mKVTLD/BBOrrMF8nz6BoFDqvhN7kn350Gaj9qO9An2cR J+4hpTJ/w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9nSe-0003zQ-Tl; Wed, 10 Feb 2021 11:15:09 +0000 Received: from relay8-d.mail.gandi.net ([217.70.183.201]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9nSW-0003uz-R6 for linux-mtd@lists.infradead.org; Wed, 10 Feb 2021 11:15:02 +0000 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 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210210_061501_024354_8E22FFE0 X-CRM114-Status: GOOD ( 21.17 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Vignesh Raghavendra , fuse-devel , Richard Weinberger , linux-kernel , Boris Brezillon , linux-mtd , Ron Minnich , sven Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org SGkgTWlrbG9zLAoKTWlrbG9zIFN6ZXJlZGkgPG1pa2xvc0BzemVyZWRpLmh1PiB3cm90ZSBvbiBX ZWQsIDEwIEZlYiAyMDIxIDExOjE2OjQ1CiswMTAwOgoKPiBPbiBUdWUsIEZlYiA5LCAyMDIxIGF0 IDEwOjM5IFBNIFJpY2hhcmQgV2VpbmJlcmdlciA8cmljaGFyZEBub2QuYXQ+IHdyb3RlOgo+ID4K PiA+IE1pa2xvcywKPiA+Cj4gPiAtLS0tLSBVcnNwcsO8bmdsaWNoZSBNYWlsIC0tLS0tICAKPiA+ ID4gSWYgeW91IGxvb2sgYXQgZnVzZV9kb19pb2N0bCgpIGl0IGRvZXMgdmFyaWFibGUgbGVuZ3Ro IGlucHV0IGFuZAo+ID4gPiBvdXRwdXQgYXQgdGhlIHNhbWUgdGltZS4gIEkgZ3Vlc3MgeW91IG5l ZWQgc29tZXRoaW5nIHNpbWlsYXIgdG8gdGhhdC4gIAo+ID4KPiA+IEknbSBub3Qgc3VyZSB3aGV0 aGVyIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkuCj4gPgo+ID4gSW4gTVVTRSBvbmUgdXNlIGNhc2Ug d291bGQgYmUgYXR0YWNoaW5nIHR3byBkaXN0aW5jdCAodmFyaWFibGUgbGVuZ3RoKSBidWZmZXJz IHRvIGEKPiA+IHNpbmdsZSBGVVNFIHJlcXVlc3QsIGluIGJvdGggZGlyZWN0aW9ucy4KPiA+IElm IEkgcmVhZCBmdXNlX2RvX2lvY3RsKCkgY29ycmVjdGx5LCBpdCBhdHRhY2hlcyBhbHdheXMgYSBz aW5nbGUgYnVmZmVyIHBlciByZXF1ZXN0Cj4gPiBidXQgZG9lcyBtdWx0aXBsZSByZXF1ZXN0cy4g IAo+IAo+IFJpZ2h0Lgo+IAo+ID4gSW4gTVVTRSB3ZSBjb2xkIGdvIHRoZSBzYW1lIHBhdGggYW5k IGlzc3VlIHVwIHRvIHR3byByZXF1ZXN0cy4KPiA+IE9uZSBmb3IgaW4tYmFuZCBhbmQgb3B0aW9u YWxseSBhIHNlY29uZCBvbmUgZm9yIHRoZSBvdXQtb2YtYmFuZCBkYXRhLgo+ID4gSG1tbT8gIAo+ IAo+IERvZXMgaW4tYmFuZCBhbmQgT09CIGRhdGEgbmVlZCB0byBiZSBoYW5kbGVkIHRvZ2V0aGVy PwoKU2hvcnQgYW5zd2VyOiB5ZXMuCgo+IElmIHNvLCB0aGVuIHR3byByZXF1ZXN0cyBpcyBub3Qg YSBnb29kIG9wdGlvbi4KCk1vcmUgZGV0YWlsZWQgYW5zd2VyOgoKVGhlcmUgaXMgYSB0eXBlIG9m IE1URCBkZXZpY2UgKE5BTkQgZGV2aWNlcykgd2hpY2ggYXJlIGNvbXBvc2VkLCBmb3IKZWFjaCBw YWdlLCBvZiBYIGluLWJhbmQgYnl0ZXMgcGx1cyBZIG91dC1vZi1iYW5kIG1ldGFkYXRhIGJ5dGVz LgoKQWNjZXNzaW5nIGVpdGhlciB0aGUgaW4tYmFuZCBkYXRhLCBvciB0aGUgb3V0LW9mLWJhbmQg ZGF0YSwgb3IgYm90aCBhdAp0aGUgc2FtZSB0aW1lIGFyZSBhbGwgdmFsaWQgdXNlIGNhc2VzLgoK KiBSZWFkIG9wZXJhdGlvbiBkZXRhaWxzOgogIEZyb20gYSBoYXJkd2FyZSBwb2ludCBvZiB2aWV3 LCB0aGUgb3V0LW9mLWJhbmQgZGF0YSBpcyAoYWxtb3N0KQogIGFsd2F5cyByZXRyaWV2ZWQgd2hl biB0aGUgaW4tYmFuZCBkYXRhIGlzIHJlYWQgYmVjYXVzZSBpdCBjb250YWlucwogIG1ldGEtZGF0 YSB1c2VkIHRvIGNvcnJlY3QgZXZlbnR1YWwgYml0ZmxpcHMuIEluIHRoaXMgY2FzZSwgaWYgYm90 aAogIGFyZWFzIGFyZSByZXF1ZXN0ZWQsIGl0IGlzIGhpZ2hseSBub24tZWZmaWNpZW50IHRvIGRv IHR3byByZXF1ZXN0cywKICB0aGF0J3Mgd2h5IHRoZSBNVEQgY29yZSBhbGxvd3MgdG8gZG8gYm90 aCBhdCB0aGUgc2FtZSB0aW1lLgoqIFdyaXRlIG9wZXJhdGlvbiBkZXRhaWxzOgogIEV2ZW4gd29y c2UsIGluIHRoZSB3cml0ZSBjYXNlLCB5b3UgKm11c3QqIHdyaXRlIGJvdGggYXQgdGhlIHNhbWUK ICB0aW1lLiBJdCBpcyBwaHlzaWNhbGx5IGltcG9zc2libGUgdG8gZG8gb25lIGFmdGVyIHRoZSBv dGhlciAoc3RpbGwKICB3aXRoIGFjdHVhbCBoYXJkd2FyZSwgb2YgY291cnNlKS4KClRoYXQgaXMg d2h5IGl0IGlzIHByZWZlcmFibGUgdGhhdCBNVVNFIHdpbGwgYmUgYWJsZSB0byBhY2Nlc3MgYm90 aCBpbgphIHNpbmdsZSByZXF1ZXN0LgoKVGhhbmtzLApNaXF1w6hsCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTGludXggTVREIGRpc2N1c3Np b24gbWFpbGluZyBsaXN0Cmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGlu Zm8vbGludXgtbXRkLwo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21846C4332B for ; Wed, 10 Feb 2021 11:24:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 02E8B64E4B for ; Wed, 10 Feb 2021 11:24:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231803AbhBJLXv convert rfc822-to-8bit (ORCPT ); Wed, 10 Feb 2021 06:23:51 -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