From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Richard Weinberger <richard@nod.at>
Cc: vigneshr@ti.com, miklos@szeredi.hu,
fuse-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
boris.brezillon@collabora.com, linux-mtd@lists.infradead.org,
rminnich@google.com, sven@narfation.org
Subject: Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
Date: Thu, 28 Jan 2021 11:30:26 +0100 [thread overview]
Message-ID: <20210128113026.094b07b0@xps13> (raw)
In-Reply-To: <20210124232007.21639-1-richard@nod.at>
Hi Richard,
Richard Weinberger <richard@nod.at> wrote on Mon, 25 Jan 2021 00:19:59
+0100:
> I'm happy to announce the first non-RFC version of this patch set.
> Over the xmas holidays I found some time to experiment with various userspace
> implementations of MTDs and gave the kernel side more fine-tuning.
>
> Rationale:
> ----------
>
> When working with flash devices a common task is emulating them to run various
> tests or inspect dumps from real hardware. To achieve that we have plenty of
> emulators in the MTD subsystem: mtdram, block2mtd, nandsim.
>
> Each of them implements an ad-hoc MTD and have various drawbacks.
> Over the last years some developers tried to extend them but these attempts
> often got rejected because they added just more adhoc feature instead of
> addressing overall problems.
>
> MUSE is a novel approach to address the need of advanced MTD emulators.
> Advanced means in this context supporting different (vendor specific) image
> formats, different ways for fault injection (fuzzing) and recoding/replaying
> IOs to emulate power cuts.
>
> The core goal of MUSE is having the complexity on the userspace side and
> only a small MTD driver in kernelspace.
> While playing with different approaches I realized that FUSE offers everything
> we need. So MUSE is a little like CUSE except that it does not implement a
> bare character device but an MTD.
I can't tell if your MUSE implementation is right but it looks fine
on the MTD side.
This is following the right path, I look forward to merging it soon!
Thanks for your contribution,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Richard Weinberger <richard@nod.at>
Cc: miklos@szeredi.hu, vigneshr@ti.com,
boris.brezillon@collabora.com, rminnich@google.com,
sven@narfation.org, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, fuse-devel@lists.sourceforge.net
Subject: Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
Date: Thu, 28 Jan 2021 11:30:26 +0100 [thread overview]
Message-ID: <20210128113026.094b07b0@xps13> (raw)
In-Reply-To: <20210124232007.21639-1-richard@nod.at>
Hi Richard,
Richard Weinberger <richard@nod.at> wrote on Mon, 25 Jan 2021 00:19:59
+0100:
> I'm happy to announce the first non-RFC version of this patch set.
> Over the xmas holidays I found some time to experiment with various userspace
> implementations of MTDs and gave the kernel side more fine-tuning.
>
> Rationale:
> ----------
>
> When working with flash devices a common task is emulating them to run various
> tests or inspect dumps from real hardware. To achieve that we have plenty of
> emulators in the MTD subsystem: mtdram, block2mtd, nandsim.
>
> Each of them implements an ad-hoc MTD and have various drawbacks.
> Over the last years some developers tried to extend them but these attempts
> often got rejected because they added just more adhoc feature instead of
> addressing overall problems.
>
> MUSE is a novel approach to address the need of advanced MTD emulators.
> Advanced means in this context supporting different (vendor specific) image
> formats, different ways for fault injection (fuzzing) and recoding/replaying
> IOs to emulate power cuts.
>
> The core goal of MUSE is having the complexity on the userspace side and
> only a small MTD driver in kernelspace.
> While playing with different approaches I realized that FUSE offers everything
> we need. So MUSE is a little like CUSE except that it does not implement a
> bare character device but an MTD.
I can't tell if your MUSE implementation is right but it looks fine
on the MTD side.
This is following the right path, I look forward to merging it soon!
Thanks for your contribution,
Miquèl
next prev parent reply other threads:[~2021-01-28 10:31 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 ` Miquel Raynal [this message]
2021-01-28 10:30 ` [PATCH 0/8] MUSE: Userspace backed MTD v3 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
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=20210128113026.094b07b0@xps13 \
--to=miquel.raynal@bootlin.com \
--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=richard@nod.at \
--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.