1<!--$Id: faq.so,v 1.30 2004/08/17 13:45:35 sue Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: VxWorks FAQ</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<a name="2"><!--meow--></a><a name="3"><!--meow--></a> 12<table width="100%"><tr valign=top> 13<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Building Berkeley DB for VxWorks systems</dl></b></td> 14<td align=right><a href="/build_vxworks/notes.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/upgrade/version.html"><img src="/images/next.gif" alt="Next"></a> 15</td></tr></table> 16<p align=center><b>VxWorks FAQ</b></p> 17<ol> 18<p><li><b>I get the error "Workspace open failed: This project workspace is an 19older format.", when trying to open the supplied workspace on Tornado 2.0 20under Windows.</b> 21<p>This error will occur if the files were extracted in a manner that adds 22a CR/LF to lines in the file. Make sure that you download the Berkeley DB 23".zip" version of the Berkeley DB distribution, and, when extracting the Berkeley DB 24sources, that you use an unzipper program that will not do any 25conversion.</p> 26<p><li><b>I sometimes see spurious output errors about temporary directories.</b> 27<p>These messages are coming from the <b>stat</b>(2) function call 28in VxWorks. Unlike other systems, there may not be a well known 29temporary directory on the target. Therefore, we highly recommend that 30all applications use <a href="/api_c/env_set_tmp_dir.html">DB_ENV->set_tmp_dir</a> to 31specify a temporary directory for the application.</p> 32<p><li><b>How can I build Berkeley DB without using Tornado?</b> 33<p>The simplest way to build Berkeley DB without using Tornado is to configure 34Berkeley DB on a UNIX system, and then use the Makefile and include files 35generated by that configuration as the starting point for your build. 36The Makefile and include files are created during configuration, in the 37current directory, based on your configuration decisions (for example, 38debugging vs. non-debugging builds), so you'll need to configure the 39system for the way you want Berkeley DB to be built.</p> 40<p>Additionally, you'll need to account for the slight difference between 41the set of source files used in a UNIX build and the set used in a 42VxWorks build. You can use the following command to create a list of 43the Berkeley DB VxWorks files. The commands assume you are in the build_vxworks 44directory of the Berkeley DB distribution:</p> 45<blockquote><pre>% cat > /tmp/files.sed 46s/<BEGIN> FILE_// 47s/_objects// 48^D 49% grep FILE_ BerkeleyDB.wpj | grep _objects | sed -f /tmp/files.sed > /tmp/db.files</pre></blockquote> 50<p>You will then have a template Makefile and include files, and a list of 51VxWorks-specific source files. You will need to convert this Makefile 52and list of files into a form that is acceptable to your specific build 53environment.</p> 54<p><li><b>Does Berkeley DB use floating point registers?</b> 55<p>Yes, there are a few places in Berkeley DB where floating point computations 56are performed. As a result, all applications that call 57<i>taskSpawn</i> should specify the <b>VX_FP_TASK</b> option.</p> 58<p><li><b>Can I run the test suite under VxWorks?</b> 59<p>The test suite requires the Berkeley DB Tcl library. In turn, this library 60requires Tcl 8.4 or greater. In order to run the test suite, you would 61need to port Tcl 8.4 or greater to VxWorks. The Tcl shell included in 62<i>windsh</i> is not adequate for two reasons. First, it is based on 63Tcl 8.0. Second, it does not include the necessary Tcl components for 64adding a Tcl extension.</p> 65<p><li><b>Are all Berkeley DB features available for VxWorks?</b> 66<p>All Berkeley DB features are available for VxWorks with the exception of the 67<a href="/api_c/db_open.html#DB_TRUNCATE">DB_TRUNCATE</a> flag for <a href="/api_c/db_open.html">DB->open</a>. The underlying mechanism 68needed for that flag is not available consistently across different file 69systems for VxWorks.</p> 70<p><li><b>Are there any constraints using particular filesystem drivers?</b> 71<p>There are constraints using the dosFs filesystems with Berkeley DB. Namely, 72you must configure your dosFs filesystem to support long filenames if 73you are using Berkeley DB logging in your application. The VxWorks' dosFs 741.0 filesystem, by default, uses the old MS-DOS 8.3 file-naming 75constraints, restricting to 8 character filenames with a 3 character 76extension. If you have configured with VxWorks' dosFs 2.0 you should 77be compatible with Windows FAT32 filesystems which supports long 78filenames.</p> 79<p><li><b>Are there any dependencies on particular filesystem drivers?</b> 80<p>There is one dependency on specifics of filesystem drivers in the port 81of Berkeley DB to VxWorks. Berkeley DB synchronizes data using the FIOSYNC function 82to ioctl() (another option would have been to use the FIOFLUSH function 83instead). The FIOSYNC function was chosen because the NFS client driver, 84nfsDrv, only supports it and doesn't support FIOFLUSH. All local file 85systems, as of VxWorks 5.4, support FIOSYNC -- with the exception of 86rt11fsLib, which only supports FIOFLUSH. To use rt11fsLib, you will need 87to modify the os/os_fsync.c file to use the FIOFLUSH function; note that 88rt11fsLib cannot work with NFS clients.</p> 89<p><li><b>Are there any known filesystem problems?</b> 90<p>During the course of our internal testing, we came across three problems 91with the dosFs 2.0 filesystem that warranted patches from Wind River Systems. 92We strongly recommend you upgrade to dosFs 2.2, <b>SPR 79795 (x86)</b> 93and <b>SPR 79569 (PPC)</b> which fixes all of these problems and 94many more. You should ask Wind River Systems for the patches to these 95problems if you encounter them and are unable to upgrade to dosFs 2.2.</p> 96<p>The first problem is that files will seem to disappear. You should 97look at <b>SPR 31480</b> in the Wind River Systems' Support pages for 98a more detailed description of this problem.</p> 99<p>The second problem is a semaphore deadlock within the dosFs filesystem 100code. Looking at a stack trace via CrossWind, you will see two or more of 101your application's tasks waiting in semaphore code within dosFs. The patch 102for this problem is under <b>SPR 33221</b> at Wind River Systems. 103There are several SPR numbers at Wind River Systems that refer to this 104particular problem.</p> 105<p>The third problem is that all tasks will hang on a dosFs semaphore. You should 106look at <b>SPR 72063</b> in the Wind River Systems' Support pages for 107a more detailed description of this problem.</p> 108<p><li><b>Are there any filesystems I cannot use?</b> 109<p>Currently both the Target Server File System (TSFS) and NFS are not able 110to be used.</p> 111<p>The Target Server File System (TSFS) uses the netDrv driver. This driver 112does not support any ioctl that allows flushing to the disk, nor does 113it allow renaming of files via FIORENAME. 114The NFS file system uses nfsDrv and that driver 115does not support FIORENAME and cannot be used 116with Berkeley DB. </p> 117<p><li><b>What VxWorks primitives are used for mutual exclusion in Berkeley DB?</b> 118<p>Mutexes inside of Berkeley DB use the basic binary semaphores in VxWorks. The 119mutexes are created using the FIFO queue type.</p> 120<p><li><b>What are the implications of VxWorks' mutex implementation 121using microkernel resources?</b> 122<p>On VxWorks, the semaphore primitives implementing mutexes consume system 123resources. Therefore, if an application unexpectedly fails, those 124resources could leak. Berkeley DB solves this problem by always allocating 125mutexes in the persistent shared memory regions. Then, if an 126application fails, running recovery or explicitly removing the database 127environment by calling the <a href="/api_c/env_remove.html">DB_ENV->remove</a> method will allow Berkeley DB to 128release those previously held mutex resources. If an application 129specifies the <a href="/api_c/env_open.html#DB_PRIVATE">DB_PRIVATE</a> flag (choosing not to use persistent 130shared memory), and then fails, mutexes allocated in that private memory 131may leak their underlying system resources. Therefore, the 132<a href="/api_c/env_open.html#DB_PRIVATE">DB_PRIVATE</a> flag should be used with caution on VxWorks.</p> 133</ol> 134<table width="100%"><tr><td><br></td><td align=right><a href="/build_vxworks/notes.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/upgrade/version.html"><img src="/images/next.gif" alt="Next"></a> 135</td></tr></table> 136<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 137</body> 138</html> 139