1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
|
<?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_61_toc.html" title="Chapter 9. Upgrading Berkeley DB 12.1.6.0 applications to Berkeley DB 12.1.6.1" />
</head>
<body>
<div xmlns="" class="navheader">
<div class="libver">
<p>Library Version 12.1.6.1</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_61_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_61_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 12.1.6.0 applications to Berkeley DB 12.1.6.1 </td>
</tr>
</table>
</div>
</body>
</html>
|
