Generic techniques to reduce the size of the IFS

The IPL copies the IFS from flash memory into RAM. The kernel and the applications can begin running only after this copy operation is complete. Therefore, the smaller you make the IFS, the sooner those components can run. Here are some general techniques that you can use:

Remove unused executables

Remove executables from the image only if the benefits of doing so outweigh the loss of useful tools.

Note that you don't have to manually strip executables of their debug information; mkifs takes care of that automatically. Note that mkefs doesn't automatically strip binaries—you should do this in your makefile.

Use symbolic links

Shared libraries in POSIX systems, including the QNX Neutrino RTOS, typically have two representations in the filesystem: a regular filename (with a version number) and a symbolic link (without a version number). For instance, libc.so.2 and libc.so. The target system should contain both representations; thus, code that requires a specific version of the shared library can link to that version, and code that doesn't care can link to the generic version. On Windows, which doesn't support true symbolic links, the QNX development installation creates duplicates of linked files, instead of symbolic links.

If you use both versioned and nonversioned representations of shared objects on your target, make a symbolic link to the other, either in the QNX Momentics IDE or in the boot script. Otherwise, you risk ending up with two distinct copies of the executable in the IFS. Since many shared libraries can be rather large (libc.so, for instance, ranges from 600 KB to 700 KB), performing this step can reduce the IFS size significantly.

Move selected files into an external filesystem

If a file doesn't need to start early in the boot process, move it into a flash external filesystem. The smallest IFS consists of the kernel, libc, a UART driver, a flash driver, and little else. After the flash driver loads, it can automount the external filesystem partitions, and you can start running the remainder of your drivers or applications files from there.

There is a trade-off here, of course. The IFS is completely loaded from flash into RAM as one big chunk. Once loaded into the IFS, any executables that you run out of IFS will load from RAM into RAM. For external filesystems, the files are loaded out of flash into RAM each time they're needed. So if you need to load an executable multiple times during bootup, it may be better to leave it in IFS since you pay the flash-copying penalty only the first time.