On Thu, Aug 26, 2010 at 6:02 PM, Paweł Hajdan, Jr. <phajdan...@chromium.org>wrote:
> Please take a look at chromium_sqlite3 functions in > > http://src.chromium.org/viewvc/chrome/trunk/src/third_party/sqlite/src/src/os_unix.c?view=markup > > They are needed because in Chrome the browser process will pass a file > descriptor to the child renderer process instead of a file path. Here's the > code that handles it on the renderer side: > > http://trac.webkit.org/browser/trunk/WebCore/platform/sql/chromium/SQLiteFileSystemChromiumPosix.cpp > > Currently those chromium_sqlite3 functions live in patched os_unix.c file > because they access slite internals that are only visible in os_unix.c. > > Could you suggest a way to do the same thing in a way that wouldn't require > custom patches on the Chromium project side? If we can get a similar > interface exposed in sqlite that'd be great. Another possible solution > would > be to allow those chromium_sqlite3 functions to be implemented outside of > os_unix.c file (that will probably require exposing more internals from > that > file). > The VFS interface is published, stable, and documented. I think the VFS is the interface you should be using. You do not have to patch os_unix.c. Leave it unchanged. Instead, create your own os_chromium.c based off of your patched os_unix.c (changing just a few identifiers to avoid conflicts) and link it with your process as a separate file. (You really should be using the SQLite amalgamation file sqlite3.c - not separate source files - since the amalgamation runs about 5% or 10% faster due to better compiler optimizations.) At start-time, simply call sqlite3_vfs_register() to register your customized VFS with SQLite. Then use sqlite3_open_v2() to specify your custom VFS implementation. Or make your custom VFS implementation the default when you register it. Another option is for you to append your custom routines to the end of sqlite3.c. cat sqlite3.c chromium_vfs.c >chromium_sqlite3.c That why, you custom routine will have access to all of the SQLite internals. Of course, those internals will change from time to time. We do not gratuitously change things, but every not and then we do refactor interfaces to add new features or to make them more efficient. So the custom code you append would need to track those changes. If we were to expose the interfaces that you are using, that means we would have to lock them down and support them forever. That would preclude many future enhancements and is something we are very reluctant to do. > _______________________________________________ > 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
