On Tue, Aug 31, 2010 at 1:19 PM, Paweł Hajdan, Jr. <phajdan...@chromium.org>wrote:
> On Fri, Aug 27, 2010 at 18:27, Paweł Hajdan, Jr. <phajdan...@chromium.org > >wrote: > > > > > > >> At start-time, simply call sqlite3_vfs_register() to register your > >> customized VFS with SQLite. > >> > > > > That's what our implementation effectively does, see > > > http://trac.webkit.org/browser/trunk/WebCore/platform/sql/chromium/SQLiteFileSystemChromiumPosix.cpp > > . > > > > Would it be possible to add a variant of the unix vfs inside of > os_unix.c? > > I'm still not sure if the current VFS interface would be sufficient for > > that. It seems that the most needed exposed call is ability to transform > a > > file path into a file descriptor > > (chromium_sqlite3_get_reusable_file_handle). > chromium_sqlite3_get_reusable_file_handle > > currently needs access to things like unixFile, findReusableFd, > > UnixUnusedFd, and sqlite3_malloc. Would you have any suggestions how to > fit > > that into the SQLite's VFS implementation? > > > > Let me clarify what the current implementation in Chrome and WebKit does. > I'd appreciate suggestions how to fit it into the SQLite API, and I'd be > glad to do the necessary work. > > So let's start with > > http://trac.webkit.org/browser/trunk/WebCore/platform/sql/chromium/SQLiteFileSystemChromiumPosix.cpp > . > In SQLiteFileSystem::registerSQLiteVFS (line 171), we register our own > SQLite VFS ("chromium_vfs") mostly based on the Unix VFS with a few > overrides. > My suggestion is that you make a copy of the os_unix.c source file (call it chromium_vfs.c or anything else that you like) and apply your edits to that copy. Since you started with an exact copy of the original os_unix.c source file, your copy will all the internal utilities and mechanisms as os_unix.c. You can use all those internal mechanism as much as you want. Then compile your customized VFS separately and add it to SQLite at start-time using sqlite3_vfs_register(). Why won't that work for you? > > Now please take a look at chromiumOpen (line 62). This code runs in the > sandboxed renderer process, and does not have direct access to the > filesystem. It uses ChromiumBridge to communicate with the outside world > (it communicates with the main browser process via IPC, and the browser > process acts as a broker). So as you can see the renderer sends most of the > details to the browser process (which runs with full user's rights), and > gets back a file descriptor. > > And the hard part now is that we need to pass that file descriptor to > SQLite. However, the public SQLite APIs all seem to be path-based. However, > the internals of os_unix.c have definitions of unixFile, findReusableFd, > UnixUnusedFd that allow us to make SQLite use the file descriptor we got. > > Please note that we get the file descriptor via ChromiumBridge, a class > that > lives in WebKit. This makes it non-trivial to put the entire implementation > of "chromium_vfs" in SQLite, because we need to ask the browser process for > the file descriptor. And we can't have the entire implementation on the > WebKit/Chrome side either, because then we can't compile against vanilla > SQLite (and Linux distributions don't like it). > > Could you suggest a better way to do the above, that would fit better > within > SQLite's design? Please let me know if you have more questions about how we > currently use SQLite, the multi-process architecture of Chrome, etc. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
