> 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 explain in detail where this "can't" comes from and what's the problem with Richard's suggestion to copy necessary pieces of code from os_unix.c to your SQLiteFileSystemChromiumPosix.cpp? If you are just scared of words "copy-paste the code" then think of it as if you write your own implementation of VFS, it just accidentally happened that in many places it looks very similar as os_unix.c. There's no other way to perfectly fit into SQLite's paradigm and to be compiled and work with vanilla SQLite. Pavel 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. > > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
