~ubuntu-branches/ubuntu/edgy/rpm/edgy

« back to all changes in this revision

Viewing changes to db/docs/ref/build_vxworks/faq.html

  • Committer: Bazaar Package Importer
  • Author(s): Joey Hess
  • Date: 2002-01-22 20:56:57 UTC
  • Revision ID: james.westby@ubuntu.com-20020122205657-l74j50mr9z8ofcl5
Tags: upstream-4.0.3
ImportĀ upstreamĀ versionĀ 4.0.3

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
<!--$Id: faq.so,v 1.21 2001/06/25 13:40:42 bostic Exp $-->
 
2
<!--Copyright 1997-2001 by Sleepycat Software, Inc.-->
 
3
<!--All rights reserved.-->
 
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,b+tree,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><h3><dl><dt>Berkeley DB Reference Guide:<dd>Building Berkeley DB for VxWorks systems</dl></h3></td>
 
14
<td align=right><a href="../../ref/build_vxworks/notes.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/upgrade/version.html"><img src="../../images/next.gif" alt="Next"></a>
 
15
</td></tr></table>
 
16
<p>
 
17
<h1 align=center>VxWorks FAQ</h1>
 
18
<p><ol>
 
19
<p><li><b>I get the error "Workspace open failed: This project workspace is an
 
20
older format.", when trying to open the supplied workspace on Tornado
 
21
under Windows.</b>
 
22
<p>This error will occur if the files were extracted in a manner that adds
 
23
a CR/LF to lines in the file.  Make sure that you download the Berkeley DB
 
24
".zip" version of the Berkeley DB distribution, and, when extracting the Berkeley DB
 
25
sources, that you use an unzipper program that will not do any
 
26
conversion.
 
27
<p><li><b>How can I build Berkeley DB without using Tornado?</b>
 
28
<p>The simplest way to build Berkeley DB without using Tornado is to configure
 
29
Berkeley DB on a UNIX system, and then use the Makefile and include files
 
30
generated by that configuration as the starting point for your build.
 
31
The Makefile and include files are created during configuration, in the
 
32
current directory, based on your configuration decisions (for example,
 
33
debugging vs.  non-debugging builds), so you'll need to configure the
 
34
system for the way you want Berkeley DB to be built.
 
35
<p>Additionally, you'll need to account for the slight difference between
 
36
the set of source files used in a UNIX build and the set used in a
 
37
VxWorks build.  You can use the following command to create a list of
 
38
the Berkeley DB VxWorks files.  The commands assume you are in the build_vxworks
 
39
directory of the Berkeley DB distribution:
 
40
<p><blockquote><pre>% cat &gt; /tmp/files.sed
 
41
s/&lt;BEGIN&gt; FILE_//
 
42
s/_objects//
 
43
^D
 
44
% grep FILE_ BerkeleyDB.wpj | grep _objects | sed -f /tmp/files.sed &gt; /tmp/db.files</pre></blockquote>
 
45
<p>You will then have a template Makefile and include files, and a list of
 
46
VxWorks-specific source files.  You will need to convert this Makefile
 
47
and list of files into a form that is acceptable to your specific build
 
48
environment.
 
49
<p><li><b>Can I run the test suite under VxWorks?</b>
 
50
<p>The test suite requires the Berkeley DB Tcl library.  In turn, this library
 
51
requires Tcl 8.1 or greater.  In order to run the test suite, you would
 
52
need to port Tcl 8.1 or greater to VxWorks.  The Tcl shell included in
 
53
<i>windsh</i> is not adequate for two reasons.  First, it is based on
 
54
Tcl 8.0.  Second, it does not include the necessary Tcl components for
 
55
adding a Tcl extension.
 
56
<p><li><b>Are all Berkeley DB features available for VxWorks?</b>
 
57
<p>All Berkeley DB features are available for VxWorks with the exception of the
 
58
<a href="../../api_c/db_open.html#DB_TRUNCATE">DB_TRUNCATE</a> flag for <a href="../../api_c/db_open.html">DB-&gt;open</a>.  The underlying mechanism
 
59
needed for that flag is not available consistently across different file
 
60
systems for VxWorks.
 
61
<p><li><b>Are there any constraints using particular filesystem drivers?</b>
 
62
<p>There are constraints using the dosFs filesystems with Berkeley DB.  Namely,
 
63
you must configure your dosFs filesystem to support long filenames if
 
64
you are using Berkeley DB logging in your application.  The VxWorks' dosFs
 
65
1.0 filesystem, by default, uses the old MS-DOS 8.3 file-naming
 
66
constraints, restricting to 8 character filenames with a 3 character
 
67
extension.  If you have configured with VxWorks' dosFs 2.0 you should
 
68
be compatible with Windows FAT32 filesystems which supports long
 
69
filenames.
 
70
<p><li><b>Are there any dependencies on particular filesystem drivers?</b>
 
71
<p>There is one dependency on specifics of filesystem drivers in the port
 
72
of Berkeley DB to VxWorks.  Berkeley DB synchronizes data using the FIOSYNC function
 
73
to ioctl() (another option would have been to use the FIOFLUSH function
 
74
instead).  The FIOSYNC function was chosen because the NFS client driver,
 
75
nfsDrv, only supports it and doesn't support FIOFLUSH.  All local file
 
76
systems, as of VxWorks 5.4, support FIOSYNC -- with the exception of
 
77
rt11fsLib, which only supports FIOFLUSH.  To use rt11fsLib, you will need
 
78
to modify the os/os_fsync.c file to use the FIOFLUSH function; note that
 
79
rt11fsLib cannot work with NFS clients.
 
80
<p><li><b>Are there any known filesystem problems?</b>
 
81
<p>During the course of our internal testing, we came across two problems
 
82
with the dosFs 2.0 filesystem that warranted patches from Wind River Systems.
 
83
You should ask Wind River Systems for the patches to these
 
84
problems if you encounter them.
 
85
<p>The first problem is that files will seem to disappear.  You should
 
86
look at <b>SPR 31480</b> in the Wind River Systems' Support pages for
 
87
a more detailed description of this problem.
 
88
<p>The second problem is a semaphore deadlock within the dosFs filesystem
 
89
code.  Looking at a stack trace via CrossWind, you will see two or more of
 
90
your application's tasks waiting in semaphore code within dosFs.  The patch
 
91
for this problem is under <b>SPR 33221</b> at Wind River Systems.
 
92
<p><li><b>Are there any filesystems I cannot use?</b>
 
93
<p>The Target Server File System (TSFS) uses the netDrv driver.  This driver
 
94
does not support any ioctl that allows flushing to the disk, and therefore
 
95
cannot be used with Berkeley DB.
 
96
<p><li><b>Why aren't the utility programs part of the project?</b>
 
97
<p>The utility programs, in their UNIX-style form, are not ported to VxWorks.
 
98
The reasoning is the utility programs are essentially wrappers for the
 
99
specific Berkeley DB interface they call.  Their interface and generic model
 
100
are not the appropriate paradigm for VxWorks.  It is most likely that
 
101
specific applications will want to spawn tasks that call the appropriate
 
102
Berkeley DB function to perform the actions of some utility programs, using
 
103
VxWorks native functions.  For example, an application that spawns several
 
104
tasks that all may operate on the same database would also want to spawn
 
105
a task that calls <a href="../../api_c/lock_detect.html">lock_detect</a> for deadlock detection, but specific
 
106
to the environment used for that application.
 
107
<p><li><b>What VxWorks primitives are used for mutual exclusion in Berkeley DB?</b>
 
108
<p>Mutexes inside of Berkeley DB use the basic binary semaphores in VxWorks.  The
 
109
mutexes are created using the FIFO queue type.
 
110
<p><li><b>What are the implications of VxWorks' mutex implementation
 
111
using microkernel resources?</b>
 
112
<p>On VxWorks, the semaphore primitives implementing mutexes consume system
 
113
resources.  Therefore, if an application unexpectedly fails, those
 
114
resources could leak.  Berkeley DB solves this problem by always allocating
 
115
mutexes in the persistent shared memory regions.  Then, if an
 
116
application fails, running recovery or explicitly removing the database
 
117
environment by calling the <a href="../../api_c/env_remove.html">DB_ENV-&gt;remove</a> function will allow Berkeley DB to
 
118
release those previously held mutex resources.  If an application
 
119
specifies the <a href="../../api_c/env_open.html#DB_PRIVATE">DB_PRIVATE</a> flag (choosing not to use persistent
 
120
shared memory), and then fails, mutexes allocated in that private memory
 
121
may leak their underlying system resources.  Therefore, the
 
122
<a href="../../api_c/env_open.html#DB_PRIVATE">DB_PRIVATE</a> flag should be used with caution on VxWorks.
 
123
</ol>
 
124
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/build_vxworks/notes.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/upgrade/version.html"><img src="../../images/next.gif" alt="Next"></a>
 
125
</td></tr></table>
 
126
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
 
127
</body>
 
128
</html>