Messages in this thread | | | Subject | Re: [fuse-devel] [PATCH 0/8] MUSE: Userspace backed MTD v3 | From | Luca Risolia <> | Date | Tue, 9 Feb 2021 16:10:41 +0100 |
| |
Hi guys,
a bit OT probably: is there any chance for you to also implement mmap() for CUSE? That would be much appreciated.
Thanks
On 09/02/21 15:35, Richard Weinberger wrote: > Miklos, > > ----- Ursprüngliche Mail ----- >>> 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'm glad to hear that! > >> 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? > > Yes, I'm all for having MUSE in drivers/mtd/. > > I placed MUSE initially in fs/fuse/ because CUSE was already there and muse.c includes > fuse_i.h. So tried to be as little invasive as possible. > >>> >>> 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. > > I'll dig into this! > > Thanks, > //richard > >
| |