[PATCH 0/8] MUSE: Userspace backed MTD v3
miklos at szeredi.hu
Tue Feb 9 09:26:25 EST 2021
On Mon, Jan 25, 2021 at 12:21 AM Richard Weinberger <richard at 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 userspace
> implementations of MTDs and gave the kernel side more fine-tuning.
> 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 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?
> - OOB support is currently limited. Currently MUSE has no support for processing
> in- and out-band in the same MTD operation. It is good enough to make JFFS2
> happy. This limitation is because FUSE has no support more than one variable
> length buffer in a FUSE request.
> At least I didn’t 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.
More information about the linux-mtd