mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-16 09:06:25 +00:00
236 lines
12 KiB
HTML
236 lines
12 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||
<title>VxWorks FAQ</title>
|
||
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
|
||
<link rel="start" href="index.html" title="Berkeley DB Installation and Build Guide" />
|
||
<link rel="up" href="build_vxworks.html" title="Chapter 8. Building Berkeley DB for VxWorks" />
|
||
<link rel="prev" href="build_vxworks_notes.html" title="VxWorks notes" />
|
||
<link rel="next" href="upgrade_53_toc.html" title="Chapter 9. Upgrading Berkeley DB 11.2.5.2 applications to Berkeley DB 11.2.5.3" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 11.2.5.3</p>
|
||
</div>
|
||
<table width="100%" summary="Navigation header">
|
||
<tr>
|
||
<th colspan="3" align="center">VxWorks FAQ</th>
|
||
</tr>
|
||
<tr>
|
||
<td width="20%" align="left"><a accesskey="p" href="build_vxworks_notes.html">Prev</a> </td>
|
||
<th width="60%" align="center">Chapter 8.
|
||
Building Berkeley DB for VxWorks
|
||
</th>
|
||
<td width="20%" align="right"> <a accesskey="n" href="upgrade_53_toc.html">Next</a></td>
|
||
</tr>
|
||
</table>
|
||
<hr />
|
||
</div>
|
||
<div class="sect1" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<h2 class="title" style="clear: both"><a id="build_vxworks_faq"></a>VxWorks FAQ</h2>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="itemizedlist">
|
||
<ul type="disc">
|
||
<li>
|
||
<span class="bold">
|
||
<strong>I get the error "Workspace open failed: This project workspace is an
|
||
older format.", when trying to open the supplied workspace on Tornado 2.0
|
||
under Windows.</strong>
|
||
</span>
|
||
<p>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.</p>
|
||
</li>
|
||
<li>
|
||
<span class="bold">
|
||
<strong>I sometimes see spurious output errors about temporary directories.</strong>
|
||
</span>
|
||
<p>These messages are coming from the <code class="literal">stat</code>(2) function call
|
||
in VxWorks. Unlike other systems, there may not be a well known
|
||
temporary directory on the target. Therefore, we highly recommend that
|
||
all applications use <a href="../api_reference/C/envset_tmp_dir.html" class="olink">DB_ENV->set_tmp_dir()</a> to
|
||
specify a temporary directory for the application.</p>
|
||
</li>
|
||
<li>
|
||
<span class="bold">
|
||
<strong>How can I build Berkeley DB without using Tornado?</strong>
|
||
</span>
|
||
<p>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.</p>
|
||
<p>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:</p>
|
||
<pre class="programlisting">% cat > /tmp/files.sed
|
||
s/<BEGIN> FILE_//
|
||
s/_objects//
|
||
^D
|
||
% grep FILE_ BerkeleyDB.wpj | grep _objects | sed -f /tmp/files.sed \
|
||
> /tmp/db.files</pre>
|
||
<p>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.</p>
|
||
</li>
|
||
<li>
|
||
<span class="bold">
|
||
<strong>Does Berkeley DB use floating point registers?</strong>
|
||
</span>
|
||
<p>Yes, there are a few places in Berkeley DB where floating point computations
|
||
are performed. As a result, all applications that call
|
||
<span class="emphasis"><em>taskSpawn</em></span> should specify the <span class="bold"><strong>VX_FP_TASK</strong></span> option.</p>
|
||
</li>
|
||
<li>
|
||
<span class="bold">
|
||
<strong>Can I run the test suite under VxWorks?</strong>
|
||
</span>
|
||
<p>The test suite requires the Berkeley DB Tcl library. In turn, this library
|
||
requires Tcl 8.5 or greater. In order to run the test suite, you would
|
||
need to port Tcl 8.5 or greater to VxWorks. The Tcl shell included in
|
||
<span class="emphasis"><em>windsh</em></span> 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.</p>
|
||
</li>
|
||
<li>
|
||
<span class="bold">
|
||
<strong>Are all Berkeley DB features available for VxWorks?</strong>
|
||
</span>
|
||
<p>All Berkeley DB features are available for VxWorks with the exception of the
|
||
<a href="../api_reference/C/dbopen.html#open_DB_TRUNCATE" class="olink">DB_TRUNCATE</a> flag for <a href="../api_reference/C/dbopen.html" class="olink">DB->open()</a>. The underlying mechanism
|
||
needed for that flag is not available consistently across different file
|
||
systems for VxWorks.</p>
|
||
</li>
|
||
<li>
|
||
<span class="bold">
|
||
<strong>Are there any constraints using particular filesystem drivers?</strong>
|
||
</span>
|
||
<p>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.</p>
|
||
</li>
|
||
<li>
|
||
<span class="bold">
|
||
<strong>Are there any dependencies on particular filesystem drivers?</strong>
|
||
</span>
|
||
<p>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.</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
<span class="bold">
|
||
<strong>Are there any known filesystem problems?</strong>
|
||
</span>
|
||
</p>
|
||
<p>During the course of our internal testing, we came across three problems
|
||
with the dosFs 2.0 filesystem that warranted patches from Wind River Systems.
|
||
We strongly recommend you upgrade to dosFs 2.2, <span class="bold"><strong>SPR 79795 (x86)</strong></span>
|
||
and <span class="bold"><strong>SPR 79569 (PPC)</strong></span> which fixes all of these problems and
|
||
many more. You should ask Wind River Systems for the patches to these
|
||
problems if you encounter them and are unable to upgrade to dosFs 2.2.</p>
|
||
<p>The first problem is that files will seem to disappear. You should
|
||
look at <span class="bold"><strong>SPR 31480</strong></span> in the Wind River Systems' Support pages for
|
||
a more detailed description of this problem.</p>
|
||
<p>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 <span class="bold"><strong>SPR 33221</strong></span> at Wind River Systems.
|
||
There are several SPR numbers at Wind River Systems that refer to this
|
||
particular problem.</p>
|
||
<p>The third problem is that all tasks will hang on a dosFs semaphore. You should
|
||
look at <span class="bold"><strong>SPR 72063</strong></span> in the Wind River Systems' Support pages for
|
||
a more detailed description of this problem.</p>
|
||
</li>
|
||
<li>
|
||
<p>
|
||
<span class="bold">
|
||
<strong>Are there any filesystems I cannot use?</strong>
|
||
</span>
|
||
</p>
|
||
<p>Currently both the Target Server File System (TSFS) and NFS are not able
|
||
to be used.</p>
|
||
<p>The Target Server File System (TSFS) uses the netDrv driver. This driver
|
||
does not support any ioctl that allows flushing to the disk, nor does
|
||
it allow renaming of files via FIORENAME.
|
||
The NFS file system uses nfsDrv and that driver
|
||
does not support FIORENAME and cannot be used
|
||
with Berkeley DB. </p>
|
||
</li>
|
||
<li>
|
||
<span class="bold">
|
||
<strong>What VxWorks primitives are used for mutual exclusion in Berkeley DB?</strong>
|
||
</span>
|
||
<p>Mutexes inside of Berkeley DB use the basic binary semaphores in VxWorks. The
|
||
mutexes are created using the FIFO queue type.</p>
|
||
</li>
|
||
<li>
|
||
<span class="bold">
|
||
<strong>What are the implications of VxWorks' mutex implementation
|
||
using microkernel resources?</strong>
|
||
</span>
|
||
<p>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 <a href="../api_reference/C/envremove.html" class="olink">DB_ENV->remove()</a> method will allow Berkeley DB to
|
||
release those previously held mutex resources. If an application
|
||
specifies the <a href="../api_reference/C/envopen.html#envopen_DB_PRIVATE" class="olink">DB_PRIVATE</a> 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
|
||
<a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> flag should be used with caution on VxWorks.</p>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="build_vxworks_notes.html">Prev</a> </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="u" href="build_vxworks.html">Up</a>
|
||
</td>
|
||
<td width="40%" align="right"> <a accesskey="n" href="upgrade_53_toc.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">VxWorks notes </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Chapter 9.
|
||
Upgrading Berkeley DB 11.2.5.2 applications to Berkeley DB 11.2.5.3
|
||
</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|