Berkeley DB Reference Guide: Building Berkeley DB for VxWorks systems

VxWorks FAQ

1. Can I run the test suite under VxWorks?

   The test suite requires the Berkeley DB Tcl library. In turn, this library requires Tcl 8.1 or greater. In order to run the test suite, you would need to port Tcl 8.1 or greater to VxWorks. The Tcl shell included in windsh is not adequate for two reasons. First, it is based on Tcl 8.0. Second, it does not include the necessary Tcl components for adding a Tcl extension.

2. Are there any constraints using particular file system drivers?

   There are constraints using the dosFs file systems with DB. Namely, you must configure your dosFs file system to support long file names if you are using DB logging in your application. The VxWorks' dosFs 1.0 file system, by default, uses the old MS-DOS 8.3 file naming constraints, restricting to 8 character file names with a 3 character extension. If you have configured with VxWorks' dosFs 2.0 you should be compatible with Windows FAT32 filesystems which supports long filenames.

3. Are there any dependencies on particular file system drivers?

   There is one dependency on specifics of file system drivers in the port of Berkeley DB to VxWorks. Berkeley DB synchronizes data using the FIOSYNC function to ioctl() (another option would have been to use the FIOFLUSH function instead). The FIOSYNC function was chosen because the NFS client driver, nfsDrv, only supports it and doesn't support FIOFLUSH. All local file systems, as of VxWorks 5.4, support FIOSYNC with the exception of rt11fsLib, which only supports FIOFLUSH. To use rt11fsLib, you will need to modify the os/os_fsync.c file to use the FIOFLUSH function; note that rt11fsLib cannot work with NFS clients.

4. Are there any file systems I cannot use?

   The Target Server File System (TSFS) uses the netDrv driver. This driver does not support any ioctl that allows flushing to the disk and therefore cannot be used with Berkeley DB.

5. Why aren't the utility programs part of the project?

   The utility programs, in their Unix-style form, are not ported to VxWorks. The reasoning is the utility programs are essentially wrappers for the specific Berkeley DB interface they call. Their interface and generic model are not the appropriate paradigm for VxWorks. It is most likely that specific applications will want to spawn tasks that call the appropriate Berkeley DB function to perform the actions of some utility programs, using VxWorks native functions. For example, an application that spawns several tasks that all may operate on the same database would also want to spawn a task that calls lock_detect for deadlock detection, but specific to the environment used for that application.

6. What VxWorks primitives are used for mutual exclusion in Berkeley DB?

   Mutexes inside of Berkeley DB use the basic binary semaphores in VxWorks. The mutexes are created using the FIFO queue type.

Copyright Sleepycat Software