All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	Ron Minnich <rminnich@google.com>, sven <sven@narfation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	fuse-devel <fuse-devel@lists.sourceforge.net>
Subject: Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
Date: Wed, 10 Feb 2021 12:23:53 +0100 (CET)	[thread overview]
Message-ID: <1183985773.380599.1612956233979.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <20210210121429.4fb5ecf3@xps13>

Miquel,

----- Ursprüngliche Mail -----
>> 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.

By single request we meant FUSE op-codes. The NAND simulator in Userspace
will see just one call. My plan is to abstract it in libfuse.

Thanks,
//richard

WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	fuse-devel <fuse-devel@lists.sourceforge.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Ron Minnich <rminnich@google.com>, sven <sven@narfation.org>
Subject: Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
Date: Wed, 10 Feb 2021 12:23:53 +0100 (CET)	[thread overview]
Message-ID: <1183985773.380599.1612956233979.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <20210210121429.4fb5ecf3@xps13>

Miquel,

----- Ursprüngliche Mail -----
>> 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.

By single request we meant FUSE op-codes. The NAND simulator in Userspace
will see just one call. My plan is to abstract it in libfuse.

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2021-02-10 11:32 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-24 23:19 [PATCH 0/8] MUSE: Userspace backed MTD v3 Richard Weinberger
2021-01-24 23:19 ` Richard Weinberger
2021-01-24 23:20 ` [PATCH 1/8] fuse: Export fuse_simple_request Richard Weinberger
2021-01-24 23:20   ` Richard Weinberger
2021-01-24 23:20 ` [PATCH 2/8] fuse: Export IO helpers Richard Weinberger
2021-01-24 23:20   ` Richard Weinberger
2021-01-24 23:20 ` [PATCH 3/8] fuse: Make cuse_parse_one a common helper Richard Weinberger
2021-01-24 23:20   ` Richard Weinberger
2021-01-24 23:20 ` [PATCH 4/8] mtd: Add MTD_MUSE flag Richard Weinberger
2021-01-24 23:20   ` Richard Weinberger
2021-01-24 23:20 ` [PATCH 5/8] mtd: Allow passing a custom cmdline to cmdline line parser Richard Weinberger
2021-01-24 23:20   ` Richard Weinberger
2021-01-24 23:20 ` [PATCH 6/8] fuse: Add MUSE specific defines FUSE interface Richard Weinberger
2021-01-24 23:20   ` Richard Weinberger
2021-01-24 23:20 ` [PATCH 7/8] fuse: Implement MUSE - MTD in userspace Richard Weinberger
2021-01-24 23:20   ` Richard Weinberger
2021-01-24 23:20 ` [PATCH 8/8] MAINTAINERS: Add entry for MUSE Richard Weinberger
2021-01-24 23:20   ` Richard Weinberger
2021-01-28 10:30 ` [PATCH 0/8] MUSE: Userspace backed MTD v3 Miquel Raynal
2021-01-28 10:30   ` Miquel Raynal
2021-02-01 13:14 ` Richard Weinberger
2021-02-01 13:14   ` Richard Weinberger
2021-02-01 13:55   ` Miklos Szeredi
2021-02-01 13:55     ` Miklos Szeredi
2021-02-09 14:26 ` Miklos Szeredi
2021-02-09 14:26   ` Miklos Szeredi
2021-02-09 14:35   ` Richard Weinberger
2021-02-09 14:35     ` Richard Weinberger
2021-02-09 15:10     ` [fuse-devel] " Luca Risolia
2021-02-09 15:10       ` Luca Risolia
2021-02-09 15:22       ` Miklos Szeredi
2021-02-09 15:22         ` Miklos Szeredi
2021-02-09 15:41       ` Richard Weinberger
2021-02-09 15:41         ` Richard Weinberger
2021-02-09 15:56         ` Luca Risolia
2021-02-09 15:56           ` Luca Risolia
2021-02-09 16:04           ` Richard Weinberger
2021-02-09 16:04             ` Richard Weinberger
2021-02-09 16:28             ` Luca Risolia
2021-02-09 16:28               ` Luca Risolia
2021-02-09 16:29               ` Richard Weinberger
2021-02-09 16:29                 ` Richard Weinberger
2021-02-09 16:42                 ` Luca Risolia
2021-02-09 16:42                   ` Luca Risolia
2021-02-09 16:50                   ` Richard Weinberger
2021-02-09 16:50                     ` Richard Weinberger
2021-02-09 17:46                     ` Luca Risolia
2021-02-09 17:46                       ` Luca Risolia
2021-02-09 19:42                       ` Miklos Szeredi
2021-02-09 19:42                         ` Miklos Szeredi
2021-02-09 20:06     ` Richard Weinberger
2021-02-09 20:06       ` Richard Weinberger
2021-02-10 10:12       ` Miklos Szeredi
2021-02-10 10:12         ` Miklos Szeredi
2021-02-10 11:12         ` Richard Weinberger
2021-02-10 11:12           ` Richard Weinberger
2021-02-10 11:16         ` Miklos Szeredi
2021-02-10 11:16           ` Miklos Szeredi
2021-02-11 18:09           ` Miklos Szeredi
2021-02-11 18:09             ` Miklos Szeredi
2021-04-13 12:59             ` Miklos Szeredi
2021-04-13 12:59               ` Miklos Szeredi
2021-02-09 21:39   ` Richard Weinberger
2021-02-09 21:39     ` Richard Weinberger
2021-02-10 10:16     ` Miklos Szeredi
2021-02-10 10:16       ` Miklos Szeredi
2021-02-10 11:00       ` Richard Weinberger
2021-02-10 11:00         ` Richard Weinberger
2021-02-10 11:14       ` Miquel Raynal
2021-02-10 11:14         ` Miquel Raynal
2021-02-10 11:23         ` Richard Weinberger [this message]
2021-02-10 11:23           ` Richard Weinberger
2021-02-10 20:55           ` Miquel Raynal
2021-02-10 20:55             ` Miquel Raynal
2021-02-10 21:11             ` Richard Weinberger
2021-02-10 21:11               ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1183985773.380599.1612956233979.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=boris.brezillon@collabora.com \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miklos@szeredi.hu \
    --cc=miquel.raynal@bootlin.com \
    --cc=rminnich@google.com \
    --cc=sven@narfation.org \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.