From: Luca R. <luc...@st...> - 2012-07-15 23:24:49
|
Hello everyone, are there any plans to add the support for the mmap() system call in CUSE ? Thank you. Luca |
From: Miklos S. <mi...@sz...> - 2012-07-17 11:37:52
|
Luca Risolia <luc...@st...> writes: > Hello everyone, > > are there any plans to add the support for the mmap() system > call in CUSE ? If there's enough interest then certainly. Last time I posted patches there was basically zero reaction. Some of those patches are still valid, some need to be updated. Please try those and report what works and what doesn't and I'll help make it work. Thanks, Miklos |
From: Luca R. <luc...@st...> - 2013-07-01 22:30:01
|
In data martedì 17 luglio 2012 13:37:33, Miklos Szeredi ha scritto: > > are there any plans to add the support for the mmap() system > > call in CUSE ? > Last time I posted patches there was basically zero reaction. Some of > those patches are still valid, some need to be updated. Please try > those and report what works and what doesn't and I'll help make it work. I can give my help to test and eventually fix those patches if there is also high interest in having them merged in the mainline FUSE/CUSE framework once the tests have finished. Could you give me a link to work being done up until now? Thanks. |
From: riyakhanna <riy...@gm...> - 2014-09-06 00:12:51
|
Hi, I saw patches adding mmap() support for CUSE sometime in 2012. Is there somebody still working on this? If not, I'd be happy to work on this. Any idea on what is needed to implement this along the lines of what Linus suggested? I plan on creating fuse based virtual devices (e.g. frame buffer - uses mmap()) multiplexing on actual hardware devices. Would it be a good idea to use CUSE for this? Thanks, Riya -- View this message in context: http://fuse.996288.n3.nabble.com/mmap-support-in-CUSE-tp11022p12458.html Sent from the Fuse mailing list archive at Nabble.com. |
From: Luca R. <luc...@st...> - 2014-09-09 19:03:16
|
Hi Riya, I think no one is working on this at the moment, but I would be glad to carefully test any patch you may want to provide. 06/09/2014 02:12, riyakhanna wrote:: > Hi, > > I saw patches adding mmap() support for CUSE sometime in 2012. Is > there somebody still working on this? If not, I'd be happy to work on this. > Any idea on what is needed to > implement this along the lines of what Linus suggested? > > I plan on creating fuse based virtual devices (e.g. frame buffer - uses > mmap()) > multiplexing on actual hardware devices. Would it be a good idea to > use CUSE for this? > > Thanks, > Riya > > > > -- > View this message in context: http://fuse.996288.n3.nabble.com/mmap-support-in-CUSE-tp11022p12458.html > Sent from the Fuse mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce. > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel |
From: riya k. <riy...@gm...> - 2014-09-09 22:00:02
|
Thanks Luca! Any idea what needs to be done to the 2012 patches from Miklos? I'm a newbie and I'm not sure I understood Linus' suggestion on the patches. Any pointers would help. Thanks! Riya On Tue, Sep 9, 2014 at 1:30 PM, Luca Risolia <luc...@st...> wrote: > Hi Riya, > > I think no one is working on this at the moment, but I would be glad to > carefully test any patch you may want to provide. > > 06/09/2014 02:12, riyakhanna wrote:: >> >> Hi, >> >> I saw patches adding mmap() support for CUSE sometime in 2012. Is >> there somebody still working on this? If not, I'd be happy to work on >> this. >> Any idea on what is needed to >> implement this along the lines of what Linus suggested? >> >> I plan on creating fuse based virtual devices (e.g. frame buffer - uses >> mmap()) >> multiplexing on actual hardware devices. Would it be a good idea to >> use CUSE for this? >> >> Thanks, >> Riya >> >> >> >> -- >> View this message in context: >> http://fuse.996288.n3.nabble.com/mmap-support-in-CUSE-tp11022p12458.html >> Sent from the Fuse mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> Want excitement? >> Manually upgrade your production database. >> When you want reliability, choose Perforce. >> Perforce version control. Predictably reliable. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> _______________________________________________ >> fuse-devel mailing list >> fus...@li... >> https://lists.sourceforge.net/lists/listinfo/fuse-devel > > |
From: Luca R. <luc...@st...> - 2014-09-10 11:51:38
|
Hi Riya, Unfortunately, I did not follow the discussion between Linus and the FUSE developers. I only know that Linus suggested some cleaner alternative to the original patch. I think Miklos knows the details better. On Tuesday 09 September 2014 16:59:54 riya khanna wrote: > Thanks Luca! > > Any idea what needs to be done to the 2012 patches from Miklos? I'm a > newbie and I'm not sure I understood Linus' suggestion on the patches. > Any pointers would help. Thanks! > > Riya > > On Tue, Sep 9, 2014 at 1:30 PM, Luca Risolia > > <luc...@st...> wrote: > > Hi Riya, > > > > I think no one is working on this at the moment, but I would be glad to > > carefully test any patch you may want to provide. > > > > 06/09/2014 02:12, riyakhanna wrote:: > >> Hi, > >> > >> I saw patches adding mmap() support for CUSE sometime in 2012. Is > >> there somebody still working on this? If not, I'd be happy to work on > >> this. > >> Any idea on what is needed to > >> implement this along the lines of what Linus suggested? > >> > >> I plan on creating fuse based virtual devices (e.g. frame buffer - uses > >> mmap()) > >> multiplexing on actual hardware devices. Would it be a good idea to > >> use CUSE for this? > >> > >> Thanks, > >> Riya > >> > >> > >> > >> -- > >> View this message in context: > >> http://fuse.996288.n3.nabble.com/mmap-support-in-CUSE-tp11022p12458.html > >> Sent from the Fuse mailing list archive at Nabble.com. > >> > >> > >> ------------------------------------------------------------------------- > >> ----- Want excitement? > >> Manually upgrade your production database. > >> When you want reliability, choose Perforce. > >> Perforce version control. Predictably reliable. > >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clk > >> trk _______________________________________________ > >> fuse-devel mailing list > >> fus...@li... > >> https://lists.sourceforge.net/lists/listinfo/fuse-devel |
From: Miklos S. <mi...@sz...> - 2014-09-10 14:41:08
|
On Wed, Sep 10, 2014 at 1:48 PM, Luca Risolia <luc...@st...> wrote: > Hi Riya, > > Unfortunately, I did not follow the discussion between Linus and the FUSE > developers. I only know that Linus suggested some cleaner alternative to the > original patch. I think Miklos knows the details better. It was a long time ago, let me try to dig that out: On Fri, Jan 13, 2012 at 7:19 PM, Linus Torvalds <tor...@li...> wrote: > On Fri, Jan 13, 2012 at 9:06 AM, Miklos Szeredi <mi...@sz...> wrote: >> From: Tejun Heo <ht...@gm...> >> >> This implements memory mapping of char devices. > > I don't think this is how you want to do it. > > It seems to maintain a page list of its own, and do the magic page > fault etc behavior. Which to me smells like a really bad design. > > I would expect that what you actually want to do is to expose it as a > shared mmap, and depend on all the normal shmem support. Is there any > reason not to do that? > > I guess you don't generally have big mappings, so an argument like > "that way you can page out pages etc" may not strike you as a very > strong argument, but I'd still prefer to at least see that approach > explored. Hmm? > > Linus So essentially we should just use shmem as backing for the cuse mmap, and store/retrieve data with FUSE_NOTIFY_STORE/FUSE_NOTIFY_RETRIEVE. Thanks, Miklos |
From: riya k. <riy...@gm...> - 2014-12-08 07:54:53
|
Hi Miklos, Is there a way to revoke/remap CUSE mmap mappings with the proposed store/retrieve notify callbacks? To be able to efficiently emulate a device, I need a way to dynamically change client's mappings from actual I/O memory to a shmem-based backup memory area depending on the permissions granted or denied respectively by the user to access I/O memory. Is there a way to accomplish this? Can I use the vm_ops->fault handler to do this at runtime? Please let me know. Thanks, Riya On Wed, Sep 10, 2014 at 8:11 PM, Miklos Szeredi <mi...@sz...> wrote: > On Wed, Sep 10, 2014 at 1:48 PM, Luca Risolia > <luc...@st...> wrote: >> Hi Riya, >> >> Unfortunately, I did not follow the discussion between Linus and the FUSE >> developers. I only know that Linus suggested some cleaner alternative to the >> original patch. I think Miklos knows the details better. > > It was a long time ago, let me try to dig that out: > > On Fri, Jan 13, 2012 at 7:19 PM, Linus Torvalds > <tor...@li...> wrote: >> On Fri, Jan 13, 2012 at 9:06 AM, Miklos Szeredi <mi...@sz...> wrote: >>> From: Tejun Heo <ht...@gm...> >>> >>> This implements memory mapping of char devices. >> >> I don't think this is how you want to do it. >> >> It seems to maintain a page list of its own, and do the magic page >> fault etc behavior. Which to me smells like a really bad design. >> >> I would expect that what you actually want to do is to expose it as a >> shared mmap, and depend on all the normal shmem support. Is there any >> reason not to do that? >> >> I guess you don't generally have big mappings, so an argument like >> "that way you can page out pages etc" may not strike you as a very >> strong argument, but I'd still prefer to at least see that approach >> explored. Hmm? >> >> Linus > > So essentially we should just use shmem as backing for the cuse mmap, > and store/retrieve data with FUSE_NOTIFY_STORE/FUSE_NOTIFY_RETRIEVE. > > Thanks, > Miklos |
From: riya k. <riy...@gm...> - 2014-12-18 11:26:51
|
Hi Miklos, What is the purpose of FUSE_NOTIFY_STORE/FUSE_NOTIFY_RETRIEVE handlers? Thanks, Riya On Wed, Sep 10, 2014 at 8:11 PM, Miklos Szeredi <mi...@sz...> wrote: > On Wed, Sep 10, 2014 at 1:48 PM, Luca Risolia > <luc...@st...> wrote: >> Hi Riya, >> >> Unfortunately, I did not follow the discussion between Linus and the FUSE >> developers. I only know that Linus suggested some cleaner alternative to the >> original patch. I think Miklos knows the details better. > > It was a long time ago, let me try to dig that out: > > On Fri, Jan 13, 2012 at 7:19 PM, Linus Torvalds > <tor...@li...> wrote: >> On Fri, Jan 13, 2012 at 9:06 AM, Miklos Szeredi <mi...@sz...> wrote: >>> From: Tejun Heo <ht...@gm...> >>> >>> This implements memory mapping of char devices. >> >> I don't think this is how you want to do it. >> >> It seems to maintain a page list of its own, and do the magic page >> fault etc behavior. Which to me smells like a really bad design. >> >> I would expect that what you actually want to do is to expose it as a >> shared mmap, and depend on all the normal shmem support. Is there any >> reason not to do that? >> >> I guess you don't generally have big mappings, so an argument like >> "that way you can page out pages etc" may not strike you as a very >> strong argument, but I'd still prefer to at least see that approach >> explored. Hmm? >> >> Linus > > So essentially we should just use shmem as backing for the cuse mmap, > and store/retrieve data with FUSE_NOTIFY_STORE/FUSE_NOTIFY_RETRIEVE. > > Thanks, > Miklos |
From: riya k. <riy...@gm...> - 2015-01-12 13:44:32
|
Hi, With CUSE mmap, is there a way to make CUSE server revoke/remap the mappings of a process - so that the process sees new mappings? Thanks! -Riya On Wed, Sep 10, 2014 at 9:41 AM, Miklos Szeredi <mi...@sz...> wrote: > On Wed, Sep 10, 2014 at 1:48 PM, Luca Risolia > <luc...@st...> wrote: >> Hi Riya, >> >> Unfortunately, I did not follow the discussion between Linus and the FUSE >> developers. I only know that Linus suggested some cleaner alternative to the >> original patch. I think Miklos knows the details better. > > It was a long time ago, let me try to dig that out: > > On Fri, Jan 13, 2012 at 7:19 PM, Linus Torvalds > <tor...@li...> wrote: >> On Fri, Jan 13, 2012 at 9:06 AM, Miklos Szeredi <mi...@sz...> wrote: >>> From: Tejun Heo <ht...@gm...> >>> >>> This implements memory mapping of char devices. >> >> I don't think this is how you want to do it. >> >> It seems to maintain a page list of its own, and do the magic page >> fault etc behavior. Which to me smells like a really bad design. >> >> I would expect that what you actually want to do is to expose it as a >> shared mmap, and depend on all the normal shmem support. Is there any >> reason not to do that? >> >> I guess you don't generally have big mappings, so an argument like >> "that way you can page out pages etc" may not strike you as a very >> strong argument, but I'd still prefer to at least see that approach >> explored. Hmm? >> >> Linus > > So essentially we should just use shmem as backing for the cuse mmap, > and store/retrieve data with FUSE_NOTIFY_STORE/FUSE_NOTIFY_RETRIEVE. > > Thanks, > Miklos |