Samba 3.0.22 Porting by Vidya Sagar

3.15 Performance Notes
You may encounter noticeable performance degradation on running some ported application on MPE/iX and
some may give good performance also. One reason behind performance degradation I believe might be due to
some extra overhead introduced as a result of implementation/simulation of POSIX APIs on MPE/iX. Another is
that MPE/iX Process creation is relatively more expensive than on UNIX systems.
Hence it is always a good idea to tune your application to adapt more into the MPE/iX environment. Please
remember that MPE/iX just simulates the POSIX environment and internally uses native calls for handling
resources. A few performance tuning tips for Samba can be found in
communicator article of Samba-3.0.22 [7] on
Jazz.
This finishes the porting of Samba-3.0.22 on MPE/iX. Your package is ready for installation on MPE/iX systems!
It is our hope that other open source freeware POSIX.1 compliant application can be successfully ported on MPE/iX by
leveraging the concepts used for Samba porting. The next section discusses few common problems and some idea how
to resolve them which may be helpful during some other port. You can also refer few other successful ports on MPE/iX
listed in
Appendix J as source of inspiration to do a fresh port or to refresh an existing port.
4 Common problems and their resolutions
This section is a general discussion of problems you may face during various phases of porting any POSIX based
application to MPE. We focus on a few selected areas which have caused problems for others in previous porting
attempts. This section complements the section “
MPE/iX limitations and major issues.”
4.1 Common Include File Problems
If a compile attempt dies because MPE is missing an include file expected by the application, first try to correct
the problem by modifying the application to NOT include the file on MPE. If the application does not use a
configure script, use the following technique to omit the include file on MPE:
#ifndef MPE
# include <foobar.h>
#endif
If the application uses GNU autoconf, examine configure.in to see if the header file in question is being checked
for existence, and if is it not, add the appropriate macro language to perform such checking. For example if
CPPFLAG does not include “-I/SYSLOG/PUB”, the script configure reports unavailability of file “syslog.h”.
Refer section
adjusting and running configure [3.5] on how to set CPPFLAG. Then modify the failing source code
like this:
#ifdef HAVE_FOOBAR_H
# include <foobar.h>
#endif
These two techniques are the most typical ways of solving most compile time problems, not just include file
problems. If the application uses GNU autoconf, modify the autoconf scripts to check for all of the functionality
the application needs. Otherwise, use the compiler’s implicit OS-based #define symbols in conjuction with
#ifdef/#ifndef to generate the correct source code.
Note that sometimes a hybrid approach is required, i.e.:
#ifdef HAVE_FOOBAR_H
# include <foobar.h>
#else
# ifdef MPE
/* do something MPE-specific */
# endif
27
#endif