![[Previous]](prev.gif) |
![[Contents]](contents.gif) |
![[Next]](next.gif) |
|
|
|
 |
This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs. |
This section is intended to discuss one way that you might approach the migration of your applications from QNX 4 to QNX Neutrino. It certainly isn't the only way, and probably not the best way for every migration situation. However, it does offer a starting point for your planning and covers a number of common situations.
Since you're moving to a new environment, your first step should be to gain some experience with the capabilities of the QNX Neutrino OS. Although this guide points out most of the items you'll have to look after during the migration, there's no substitute for getting your feet wet and finding out exactly how things really work.
The next few sections indicate one way you can build up this experience. If you don't take time to become familiar with the new OS before starting a serious migration project, you'll probably expend much more effort than necessary and have a number of false starts.
The first step is obviously to install your development system. As specified in the "Compiler & tools" section of the Development Environment chapter, your choice of hosts are:
Your migration task will be a lot easier if you can access your target system over the network using NFS or CIFS. This allows you to:
The first thing you should do is move your environment. Most of you will have customized the standard QNX environment in many ways with shell scripts and utility programs. Moving this material to QNX Neutrino will give you:
This is where you can start to get a feel for what problems you'll face during the migration of your major applications. Moving your utilities will not only give you a good feel for migration problems, but will also ensure that your standard tools are available to you when the serious work starts.
The section "Moving a program" provides some initial suggestions on how to deal with individual programs.
 |
Keep records on the effort required to migrate each utility. This will give you an estimating base when you come to plan the migration of your major applications. |
Good planning is the key to a successful migration. The following points provide a starting point for your planning efforts.
The following steps will be needed for each program.
You can use the mig4nto utility supplied with the migration kit to identify the major areas in each program that need attention. This utility identifies functions in your source programs that may require attention and provides succinct suggestions as to a course of action in each case. This utility is fully described in the next chapter.
First you must determine whether, through use of obsolete QNX functions or for other reasons, there are any architectural reasons why the program won't migrate as is. Perhaps the program performs a function that's unique to QNX 4 and isn't necessary in QNX Neutrino. Or maybe a serious redesign is required because the program is too tightly bound to QNX 4 facilities. Programs in this class should be rare, but they do have to be identified and strategies for dealing with them must be developed.
This is largely a mechanical job, but it needs to be done for each program. Many header filenames and contents have changed.
If you have hard-coded pathnames in you programs, they may need to be converted. This will be the case with nodename syntax. In QNX 4 a node was denoted using //nid where nid was the network identifier. Nodes of a QNX Neutrino network are different.
The last step is to convert your program to use QNX Neutrino functions, manifests, and data structures. The output from the mig4nto utility will be very helpful at this stage.
|
|
|