On Mon, Jan 25, 2021 at 12:21 AM Richard Weinberger <rich...@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. > > 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.
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 > 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. Thanks, Miklos