----- Ursprüngliche Mail ----- > 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 a adhoc 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. > > To get early feedback I'm sending this series as RFC, so don't consider it as > ready to merge yet. > > Open issues are: > > 1. Dummy file object > The logic around fuse_direct_io() expects a file object. > Unlike FUSE or CUSE we don't have such an object in MUSE because usually an > MTD is not opened by userspace. The kernel uses the MTD and makes it available > to filesystems or other layers such as mtdblock, mtdchar or UBI. > Currently a anon inode is (ab)used for that. > Maybe there is a better way? FYI, I'll send an updated series soon. I rewrote the MUSE IO path to not use fuse_direct_io() which made things much simpler and all hacks go away. Thanks, //richard
