Filesystem Provider API for NACL

[Sabin Flo]

Hi,

I have been browsing for a couple of days the chromium sources to see what needs to be added/modified for a fuse like pluggable filesystem.
I found that there are is a support for filesystem providers only for chromeos.

I want to extend that to be able to implement filesystem interfaces inside NACL. So here is what I am planning( I read about Pepper api proposal process ):

• Define some meaningful PPB_FilesystemProvider interfaces for the coresponding calls from File System Provider:
• mount([in] PP_Resource filesystem_provider, [in] PP_Var filesystemId, [in] PP_Var displayName, [in] PP_Bool writable, [in] int32_t, [out] PP_CompletionCallback callback )
• unmount - same
• get - same
• getAll - same
• Define some meaningful PPP_FilesystemProvider for the coresponding calls for implementations:
• onUnmountRequested( [in]PP_Instance instance, [in]PP_Var fileSystemId, [in]int32_t requestId -- how should I define the successCallback/errorCallback logic ? Need research
  
• Implement the API
• Need a ResourceHost inside the browser to reduce the IPC calls. Every ResourceHost will implement the ProvidedFilesystemInterface and forward the requests inside the Nacl plugin
• How is the EventRouter working for the extension filesystems - Need research
• chromeos::file_system_provider::Service should be modified in order to accommodate the extra logic for the FileSystemKey<pluginId, filesystemId > ( others need this to). Need to check with the owner if this is the wanted approach. The interface maps should not be that complicated to modify. Need research
• Are there aspects that I am missing

Thanks in advance for any indications on these.

[Sabin Flo]

Hi

I added the attached interfaces definitions. If someone can give me a feedback on these so that I would know that I am on the right track.

I am not  sure that the "notification" approach to get a "callback" from the client is the right solution. The biggest problem is that there is no way to enforce the calls.

[David Michael]

We don't have any examples of providing a service via Pepper that's available to other Pepper plugins. It would take a lot of work, and I'm fairly confident we wouldn't take this upstream. If this is something you want Chrome to support, it's probably a non-starter, sorry.

If you want this to be for your own experimentation or a fork of Chromium, you may want to just manually add your own kind of FileSystem within your Chromium fork. This would be a lot easier than making a general-purpose API to allow plugins to be FileSystem providers. To do that, you could try modeling it after something like PPB_IsolatedFileSystem_Private.

HTH

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

[David Michael]

I just realized I may have misunderstood your proposal. I still think it's unlikely we'd want to take this on in Pepper.

Is it possible that you could get what you need by making a JS FileSystemProvider and forwarding calls to a NaCl <embed> using postMessageAndAwaitResponse()?

[Sabin Flo]

Hi,

Thanks for the reply!

I want to do add this and test the 2 approaches( filesystem from a plugin and a filesystem from JS+plugin). I don't mind the time loss if I can prove that this is viable( but not accepted for some specific reason ) or the opposite.

I *think* that I identified the parts of the puzzle for doing it and I am looking for a validation from a high level view and maybe some heads up as I am sure that there are some aspects that elude me at this point.

[Sabin Flo]

Hi,

Following on this subject, I added the possibility to provide a file system from inside a NACL module. My approach adds a "source policy" that chooses from 2 event routers ( plugin event router and an extension event router ). When a new provided file system is requested (extension or plugin) the backend chooses the type of filesystem it wants.

The work in progress patch for the approach can be viewed here:

https://codereview.chromium.org/1093383002/

I did some testing with several file system operations and I obtained the following results with an in memory file system( I tested copying a 1GB file inside the plugin and copying it out ). The following measurements are taken at the pepper host level and represent the overall time in seconds for a 1 GB file to be passed from the browser to the plugin and reverse:

Trusted transfer browser-plugin: 4.76038(allocation+copying time 1.04689)

Trusted transfer plugin-browser: 2.43648

Nexe transfer browser-plugin: 15.6217(allocation+copying time 0.70824)

Nexe transfer plugin-browser: 3.61965

At this point I cannot explain what is causing the difference between the read and write( not taking into consideration the allocation and copying ). I can see that the "read" operation from the plugin are almost similar in the 2 modes.

Is there a difference between the IPC communication in the directions browser-to-plugin and plugin-to-browser ?

[Sabin Flo]

I want to share some recent preliminary results I've got with the https://codereview.chromium.org/1093383002/ implementation.

I have implemented a filesystem in 3 ways :

• nexe module that receives the file chunks inside IPC messages
• nexe module that receives the file chunks in a shared memory region
• extension implementation

and I moved a 1 GB file from the hard-disk filesystem to each one of the 3 and then read back. The following are the results of the operations:

1) NACL module - Embedded payload inside IPC messages

• write to plugin: 19.7953 seconds
• read from plugin: 8.06 seconds

2)NACL module - Shared Memory payload

• write to plugin: 6.99 seconds
• read from plugin: 4.744 seconds

3)"Basic" extension with few modifications

• write to extension: 15.924 seconds
• read from extension: 15.476 seconds

One can see that the NEXE filesystem with the shared memory payload performs the best. Can someone indicate if this is something that would be included in chromium ?

I can give details on the implementation.  I also asked here:

https://groups.google.com/a/chromium.org/forum/#!topic/pepper-dev/87b2zEe7C78

Thanks, 

sabin