- Berkeley DB Reference Guide:
- Building Berkeley DB for VxWorks systems
|
|
This error will occur if the files were extracted in a manner that adds a CR/LF to lines in the file. Make sure that you download the Berkeley DB ".zip" version of the Berkeley DB distribution, and, when extracting the Berkeley DB sources, that you use an unzipper program that will not do any conversion.
The simplest way to build Berkeley DB without using Tornado is to configure Berkeley DB on a UNIX system, and then use the Makefile and include files generated by that configuration as the starting point for your build. The Makefile and include files are created during configuration, in the current directory, based on your configuration decisions (for example, debugging vs. non-debugging builds), so you'll need to configure the system for the way you want Berkeley DB to be built.
Additionally, you'll need to account for the slight difference between the set of source files used in a UNIX build and the set used in a VxWorks build. You can use the following command to create a list of the Berkeley DB VxWorks files. The commands assume you are in the build_vxworks directory of the Berkeley DB distribution:
% cat > /tmp/files.sed s/<BEGIN> FILE_// s/_objects// ^D % grep FILE_ BerkeleyDB.wpj | grep _objects | sed -f /tmp/files.sed > /tmp/db.files
You will then have a template Makefile and include files, and a list of VxWorks-specific source files. You will need to convert this Makefile and list of files into a form that is acceptable to your specific build environment.
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.
All Berkeley DB features are available for VxWorks with the exception of the DB_TRUNCATE flag for DB->open. The underlying mechanism needed for that flag is not available consistently across different file systems for VxWorks.
There are constraints using the dosFs filesystems with Berkeley DB. Namely, you must configure your dosFs filesystem to support long filenames if you are using Berkeley DB logging in your application. The VxWorks' dosFs 1.0 filesystem, by default, uses the old MS-DOS 8.3 file-naming constraints, restricting to 8 character filenames 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.
There is one dependency on specifics of filesystem 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.
During the course of our internal testing, we came across two problems with the dosFs 2.0 filesystem that warranted patches from Wind River Systems. You should ask Wind River Systems for the patches to these problems if you encounter them.
The first problem is that files will seem to disappear. You should look at SPR 31480 in the Wind River Systems' Support pages for a more detailed description of this problem.
The second problem is a semaphore deadlock within the dosFs filesystem code. Looking at a stack trace via CrossWind, you will see two or more of your application's tasks waiting in semaphore code within dosFs. The patch for this problem is under SPR 33221 at Wind River Systems.
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.
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.
Mutexes inside of Berkeley DB use the basic binary semaphores in VxWorks. The mutexes are created using the FIFO queue type.
On VxWorks, the semaphore primitives implementing mutexes consume system resources. Therefore, if an application unexpectedly fails, those resources could leak. Berkeley DB solves this problem by always allocating mutexes in the persistent shared memory regions. Then, if an application fails, running recovery or explicitly removing the database environment by calling the DB_ENV->remove function will allow Berkeley DB to release those previously held mutex resources. If an application specifies the DB_PRIVATE flag (choosing not to use persistent shared memory), and then fails, mutexes allocated in that private memory may leak their underlying system resources. Therefore, the DB_PRIVATE flag should be used with caution on VxWorks.
|
|