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;
MIME-Version: 1.0
References: <20210124232007.21639-1-richard@nod.at>
In-Reply-To: <20210124232007.21639-1-richard@nod.at>
From:   Miklos Szeredi <miklos@szeredi.hu>
Date:   Tue, 9 Feb 2021 15:26:25 +0100
Message-ID: <CAJfpegvN2KdMj_7T-OF1PAs8xZiU3f4233AvigaXwwRAsgQEjw@mail.gmail.com>
Subject: Re: [PATCH 0/8] MUSE: Userspace backed MTD v3
To:     Richard Weinberger <richard@nod.at>
Cc:     Miquel Raynal <miquel.raynal@bootlin.com>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Boris Brezillon <boris.brezillon@collabora.com>,
        Ron Minnich <rminnich@google.com>, sven@narfation.org,
        linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
        fuse-devel <fuse-devel@lists.sourceforge.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Jan 25, 2021 at 12:21 AM Richard Weinberger <richard@nod.at> wrote:
>
> 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 users=
pace
> 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 va=
rious
> 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 attemp=
ts
> 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) ima=
ge
> formats, different ways for fault injection (fuzzing) and recoding/replay=
ing
> 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 every=
thing
> we need. So MUSE is a little like CUSE except that it does not implement =
a
> bare character device but an MTD.

Looks fine.

I do wonder if MUSE should go to drivers/mtd/ instead.   Long term
goal would be move CUSE to drivers/char and move the transport part of
fuse into net/fuse leaving only the actual filesystems (fuse and
virtiofs) under fs/.

But for now just moving the minimal interface needed for MUSE into a
separate header (<net/fuse.h>) would work, I guess.

Do you think that would make sense?

>
> Notes:
> ------
>
> - OOB support is currently limited. Currently MUSE has no support for pro=
cessing
>   in- and out-band in the same MTD operation. It is good enough to make J=
FFS2
>   happy. This limitation is because FUSE has no support more than one var=
iable
>   length buffer in a FUSE request.
>   At least I didn=E2=80=99t find a good way to pass more than one buffer =
to a request.
>   Maybe FUSE folks can correct me. :-)

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.

Thanks,
Miklos