mkifs

Build an OS image filesystem (QNX)

Syntax:

mkifs [-a suffix] [-l inputline] [-n[n]] [-r rootdir]
      [-s section] [-v] [buildfile [imagefile]]

Options:

-a suffix

Append a suffix to symbol files generated via [+keeplinked].

-l inputline

(el) Process inputline before interpretation of the buildfile begins. Input lines given to mkifs must be quoted to prevent interpretation by the shell (especially since mkifs input lines often contain spaces). Multiple -l options are processed in the order specified. No default.

-n[n]

Force the modification times of all inline files to be 0. If you specify -nn, mkifs sets the modification times of all files to 0.

When mkifs adds files to an IFS image, it uses the timestamp information from the file on the host machine. If mkifs is creating an inline file (which doesn't exist on the host machine), it has to generate its own timestamp information. By default, it's the time that the image is generated.

This results in different checksum values for two identical builds (because the file's creation or modification times are different). If you use -n, the checksum value is the same on all identical builds.

The -nn option addresses a quirk in NTFS relating to daylight savings time. This option forces the modification time for all files in the IFS image to be set to 0. This ensures that subsequent builds of the same IFS image have the same checksum.

-r rootdir

Search the default paths in the rootdir directory before searching them in the default location. Normally, mkifs searches the default paths in the sequence shown in MKIFS_PATH below. If you specify the -r option, mkifs first searches the same paths prefixed with the rootdir variable instead of ${QNX_TARGET}, like this:

rootdir /${PROCESSOR}/sbin
all other default paths, similarly prefixed with rootdir
${QNX_TARGET}/${PROCESSOR}/sbin
all other normal default paths prefixed with ${QNX_TARGET}

The structure of the directory paths under rootdir must be identical to that of the default paths under ${QNX_TARGET}, but rootdir itself may be any path you choose. For example, if you wanted to include this file:

/dev/ppcbe/sbin/pci-ppc405

you would specify the option like this:

-r /dev

Notice that you don't include ${PROCESSOR} in rootdir.

If you set MKIFS_PATH, mkifs ignores the -r option.

-s section

Don't strip the named section from ELF executables when creating an IFS image. You can use this option more than once to specify additional sections.

By default, mkifs doesn't strip the QNX_Phab (Photon resources), QNX_usage (usage message), and QNX_info (build properties) sections.

-v

Operate verbosely. Specifying additional -v options increases verbosity. Default is quiet operation.

Description:

The mkifs utility is used to create an OS image filesystem from a buildfile specification.

You can specify these files on the command line:

buildfile: The input buildfile that mkifs is to construct an image from; use - to specify standard input (the default).
imagefile: The file to contain the image that mkifs builds; use - to specify standard output (the default). Note that you can specify the imagefile only if you've specified the buildfile.

Buildfiles

The buildfile uses the same grammar as the mkefs command, but supports different attributes.

The buildfile specifies a list of files of various types; these files are placed by mkifs into the output image. As well as the files to be included, you can specify various attributes that are used to set parameters of the files or the image as a whole.

You can't use a backslash (\) to break long lines into smaller pieces.

In a buildfile, a pound sign (#) indicates a comment; anything between it and the end of the line is ignored. There must be a space between a buildfile command and the pound sign.

Each line is in the form:

[attributes] file_specification

where the attributes (with the enclosing square brackets) and the file specification are both optional.

You can use an attribute:

on the same line as a filename — the attribute modifies only that file
on a line by itself — the attribute modifies all subsequent files

Enclose the attributes in square brackets; when combining attributes (e.g. to specify both the user ID and the group ID), enclose both attribute tokens in the same pair of square brackets. For example:

# correct way
[uid=5 gid=5] filename

# incorrect way
[uid=5] [gid=5] filename

There are two types of attributes:

boolean attributes: Those prefixed with a plus (+) or minus (-) sign.
value attributes: Those ending with an equals sign (=) followed by a value. Don't put any spaces around the equals sign.

A question mark (?) before an attribute makes the setting conditional. The attribute is set only if it hasn't already been set. For example, ?+bigendian sets the +bigendian attribute only if +bigendian or -bigendian hasn't already been set.

The file_specification takes one of the following forms:

path: The path is the same on the host as in the image.
target_path=host_path: The specified file or contents of the specified directory are fetched from the host filesystem and placed into the image.
target_path={contents}: An inline definition. The contents of the file are listed within the buildfile itself, enclosed in braces ({ }) — the file doesn't exist on the host system anywhere. The contents of the inline file can't be on the same line as the opening or closing brace.
The mkifs utility doesn't parse the contents of an inline file for anything but the closing brace. For example, mkifs doesn't interpret a pound sign (#) in an inline file as the beginning of a comment. The syntax of the inline file depends on what it's used for on the target system.
Closing braces (}) and backslashes (\) in an inline file must be escaped with a backslash.

Either class of file may be preceded by zero or more attributes. These attributes are used to specify the characteristics of the file (e.g. the user ID that is to own the file on the target system, the type of file, etc.).

By default, mkifs strips debugging information from executable files that you include in the image. Doing this helps to reduce the size of the image. To keep this information, specify the +raw attribute.

By default, mkifs doesn't strip the QNX_Phab (Photon resources), QNX_usage (usage message), and QNX_info (build properties) sections. You can use the -s option to specify additional sections not to be stripped.

You can enclose a filename in double quotes ("") if it includes spaces or unusual characters.

Attributes

The mkifs command supports the following attributes:

+|-autolink
+|-big_pages
+|-bigendian
cd= path
chain= addr
code= uip_spec
compress
data= uip_spec
dperms= perm_spec
filter= filter_spec
+|- followlink
gid= id_spec
image= addr_space_spec
+|-keeplinked
linker= [ linker_id_spec ] linker_spec
module= module_name
+|-optional
+|-page_align
pagesizes= size[,size]...
perms= perm_spec
phys_align= size
physical= boot_spec
prefix= prefix_spec
ram= addr_space_spec
+|-raw
+|-script
search= filename : filename :…
type= file_type
uid= id_spec
virtual=[cpu_name,]bootfile_name [filter_args]

An OR-bar indicates that either the first or second element must be present, but not both (e.g. +|- bigendian means either +bigendian or -bigendian, but not +-bigendian).

autolink attribute (boolean)

+|-autolink

If the autolink attribute is on (which it is by default), when mkifs detects that it's processing a shared object, it looks inside the image for the SONAME (specified by the linker -h option). This is typically the shared object name, including the version number (e.g. libc.so.1). The mkifs command puts the file into the image filesystem under the name with the version number and makes the name without the version number into a symbolic link to the file. For example, specifying:

libc.so

in the buildfile makes libc.so.1 the name of the file and libc.so a symlink to it. Specifying:

libc.so.1

in the buildfile gives the same results. You end up with the name with and without the version number in the image filesystem no matter which one you specify in the buildfile.

If the name that would be used as the symbolic link is already specified somewhere else in the buildfile, the symbolic link isn't created. For example:

libc.so.1
libc.so.2
[type=link] libc.so=libc.so.2

ensures that libc.so is pointing at the proper version of the library.

You can disable this feature by specifying the -autolink attribute.

+|-big_pages attribute (boolean)

This attribute makes mkifs attempt to align binaries and shared libraries at the appropriate address, based on the size of the UIP text. You can use the pagesizes attribute to indicate the page sizes that the underlying hardware supports. You can specify these attributes in the buildfile or in the bootfile. The big_pages attribute is off by default.

A phys_align attribute overrides the big_pages alignment hint. For example:

[+big_pages pagesizes=4k,64k]
libc.so
[-big_pages]a_binary_that_doesnt_want_bigpages

[phys_align=1m]explicit_override_for_this_file

bigendian attribute (boolean)

+|-bigendian

Set the byte order for the image filesystem to either big (via +bigendian) or little (via -bigendian) endian. This option doesn't normally need to be specified when building a bootable image, since the bootfile provides the required byte order. If you aren't building a bootable filesystem, or the bootfile doesn't say which byte order to use, mkifs uses the host system's byte order in building the image filesystem.

cd attribute

cd=path

Set the current working directory to the specified pathname before attempting to open the host file. Default is the directory from which mkifs was invoked.

chain attribute

chain=addr

Set the address at which the operating system will find the next image filesystem. Default is none.

code attribute

code=uip_spec

Set whether the code segment of an executable is used directly from the image filesystem (uip or u) or copied (copy or c) when invoked. The default is to use the code segment in place (uip). For more information, see Notes on XIP versus copy, below.

compress attribute

+|-compress
compress=algorithm

Set whether the image is compressed. The default is false.

The first (boolean) form turns compression on or off. The algorithm is the default, UCL8.

The second form (note there's no leading + or - sign) turns compression on and specifies the algorithm by number:

1 — ZLIB
2 — LZO
3 — UCL8 (the default)

data attribute

data=uip_spec

Set whether the data segment of an executable is used directly from the image filesystem (uip or u) or copied (copy or c) when invoked. The default is to use the data segment in place (uip). For more information, see Notes on XIP versus copy, below.

dperms attribute

dperms=perm_spec

Set the access permissions of the directory. See the perms attribute for more information.

filter attribute

filter=filter_spec

Run the host file through the filter program specified, presenting the host file data as standard input to the program, and use the standard output from the program as the data to be placed into the image filesystem. Default is no filter.

To illustrate the use of a filter, consider storing a compressed file in the image filesystem, where the file exists in its uncompressed form on the host filesystem:

[filter="compress"] data.Z = data

This runs compress from a shell, passing it the contents of data as standard input. The compress command runs and generates the compressed version of its standard input on its standard output. The standard output is then placed into the image filesystem as the data.Z file.

You can specify a filter_spec of none. This is useful if you need to override a global filter specification.

followlink attribute (boolean)

[+|-followlink]target_path=host_path

If you specify +followlink or omit it, mkifs follows any links and makes target_path a copy of host_path.

If you specify -followlink, mkifs creates a link called target_path that points to whatever host_path points at. It's up to you to make sure that the file pointed to is placed in the image.

gid attribute

gid=id_spec

Set the group ID number for the file. The value of this attribute may be either a number or an asterisk (*). If it's an asterisk, the group ID is taken from the host file; for an inline file, the group ID is the group of the user running mkifs. The default value for this attribute is *.

image attribute

image=addr_space_spec

Set the base and size limits for the image filesystem. The format for this attribute consists of an optional starting address, followed by zero or more parameters for sizing the address space. You can use a case-insensitive suffix of k, m, or g on the addresses and sizes.

The starting address is the base address of the image, and matters only when building a bootable image. Its default depends on the bootfile selected. For example, on an x86 using the bios.boot file, the image address begins at 4 MB.

-end_addr: A dash followed by a number represents an ending address, the last allowable address in the image. If the output image exceeds this address, an error is reported. The default is no limit.
,maxsize: A comma followed by a number represents the maximum allowed size of the image. If the output image becomes larger than this value, an error is reported. The default is no limit. The maximum image size depends on your configuration; for example, it may be limited on an x86 system with a BIOS.
=totalsize: An equals sign followed by a number represents the total size that the output image is padded out to. The default is no padding.
%align: A percent sign followed by a number represents the alignment value used for the image. The output image size is padded out to a multiple of this value. The default is 4.

You have to specify both image and ram file attributes if you want to create the image in ROM/FLASH; otherwise the process manager assumes that the image is in RAM. For more information, see Notes on XIP versus copy, below.

keeplinked attribute (boolean)

+|-keeplinked

If true, and mkifs has to run a linker to position the executable within the image filesystem, the output file from the link is the basename of the host path with .sym appended. For example, if the host name is ../foo/bar, the output name is bar.sym. If false, a generated temporary name is used for the output file and it's deleted after mkifs has run. The default is false.

linker attribute

linker=[linker_id_spec]linker_spec

When building a bootable image, mkifs sometimes needs to run a linker on relocatable objects to position them within the image. This option lets you specify printf-like macro expansions to tell mkifs how to generate the linker command line (see Linker Specification, below for details).

You don't normally need to specify this option, since mkifs or a bootfile provides a default. You can use different linkers for different types of ELF files.

The attribute value consists of an optional linker ID specification and a linker specification. The linker ID specification, if present, consists of:

An opening parenthesis, (.
A list of comma-separated numbers giving the allowable ELF machine numbers (EM_* constants from the include file <sys/elf.h>) for the linker specification. Terminate the list of machine numbers with a semicolon.
A list of comma-separated numbers, giving the list of acceptable ELF file types (ET_* constants, from <sys/elf.h>). Terminate this list with a semicolon.
A comma-separated list of numbers giving ELF program segment types (PT_* constants, also from <sys/elf.h>).
A closing parenthesis, ).

If the ID specification is present, the linker specification is used only if the machine number of the ELF input file matches one of the given numbers, and the ELF file type of input file matches one of the given numbers and at least one of the program segment types in the input file matches one of the given numbers:

If the machine number list is empty, any machine number type in the input file is acceptable.
If the program segment number list is empty, any program segment number types in the input file are acceptable.
If the ELF file type number list is empty, ET_REL is assumed.

module attribute

module=module_name

Use this attribute to add optional modules to procnto.

optional attribute (boolean)

+|-optional

If true, and the host file can't be found, output a warning and continue building the image filesystem. If false, and the host file can't be found, output an error message and exit mkifs. The default is true. You can't set this attribute to true for bootstrap executables (see the virtual attribute for more information).

page_align attribute (boolean)

+|-page_align

If true, align the file on a page boundary. The mkifs utility always aligns executables and shared objects on page boundaries, so this attribute has an effect only on data files and files that you specify +raw for.

pagesizes attribute

pagesizes=size[,size]...

This attribute defines the page sizes that the underlying hardware supports, for use with the big_pages attribute. The sizes can be in any order, and can include a case-insensitive suffix of k, m, or g.

You can specify these attributes in the buildfile or in the bootfile.

perms attribute

perms=perm_spec

Set the access permissions of the file. The perm_spec can be one of the following:

a number (just as with the chmod command)
an asterisk (*) to use the host file's permissions (or 0666 for inline files)
a symbolic mode string to delete, add, or set permissions. This string is a subset of chmod's and consists of:
1. a combination of u, g, o, and a
2. one of -, =, or +
3. a combination of r, w, x, s, g, and t.
You can include more than one symbolic mode string, separating them with a comma (,).

The default is *.

When running on a Windows host, mkifs can't get the execute (x), setuid (set user ID), or setgid (set group ID) permissions from the file. Use the perms attribute to specify these permissions explicitly. You might also have to use the uid and gid attributes to set the ownership correctly. To determine whether or not a utility needs to have the setuid or setgid permission set, see its entry in the Utilities Reference.

ELF executables and shared objects are automatically marked as executable (unless you specify [+raw]).

phys_align attribute

phys_align=size[,group]

The phys_align attribute lets you align IFS objects on specific physical address boundaries to take advantage of large pages. The size is an integer, optionally followed by k, m, or g in lower- or uppercase. This attribute overrides the +|-big_pages attribute.

For example, to align a file on a 64 KB boundary, potentially allowing the use of 64 KB pages to map 64 KB chunks of the file, specify:

[phys_align=64k] some_executable

You can use the optional group option to group shared objects together based on an alignment size. For example:

[phys_align=16M,group]
first.so
second.so
third.so
[phys_align=0] # ends alignment

In this example, first.so is aligned to 16 MB, and each successive shared object either completely fits within that same 16 MB page, or is bumped to the next 16 MB boundary.

physical attribute

physical=[cpu_name,]boot_filename [filter_args]

This attribute indicates that a bootable filesystem is being built. You can specify it only once in a buildfile. The image will be run in physical memory mode.

The physical attribute isn't currently implemented; use virtual.

For more information, see the virtual attribute.

prefix attribute

prefix=prefix_spec

Set the prefix for the target file names. Default is proc/boot when building a bootable image, and the empty string when not.

ram attribute

ram=addr_space_spec

Set base and size limits for the read-write memory required by executables in the image filesystem. This attribute consists of an optional starting address, followed by zero or more parameters for sizing the address space. You can use a case-insensitive suffix of k, m, or g on the addresses and sizes.

You need to specify this attribute if the actual image is going to be stored on a read-only device such as ROM or flash memory. Use the image attribute to specify the location.

The starting address specifies the base address of the RAM, and matters only when building a bootable image. The default depends on the bootfile you select.

-end_addr: A dash followed by a number represents an ending address, the last allowable address for RAM. If the RAM usage exceeds this address, an error is reported. The default is no limit.
,maxsize: A comma followed by a number represents the maximum allowed size of the RAM. If the output image requires more RAM than this value, an error is reported. The default is no limit. The maximum RAM size depends on your configuration.
=totalsize: An equals sign followed by a number represents the total size that the RAM usage is padded out to. The default is no padding.
%align: A percent sign followed by a number represents the alignment value used for the RAM. The RAM size is padded out to a multiple of this value. The default is 4.

For information about how everything interacts, see Notes on XIP versus copy, below.

raw attribute (boolean)

+|-raw

If the raw attribute is false (the default), mkifs strips debugging information from executable files.

If you specify +raw for a file, the file is treated as a data file, even if it would normally be treated as an executable and relocated.

Don't specify the +raw attribute for shared objects; it prevents them from being shared.

If you use the default attribute (-raw) and you specify that the data segment is to be used in place, the file's sticky bit will not be set. This identifies the executable to the QNX process manager, which will prevent the program from running more than once, avoiding the possibility of running a program with corrupted static data.

Here's a fragment from a buildfile that demonstrates the use and scope of the raw attribute:

…

[+raw]            # Don't strip debugging information
my_app1

[-raw] esh        # Only esh is affected
pwm               # Still affected by +raw flag
pfm

[-raw]            # Turn off +raw, since shared objects
libphrender.so    # can't be shared if +raw is enabled
libph.so

[+raw] my_app2    # We want debugging information for this
                  # file only.  The -raw flag is
                  # still in effect for other files.
libc.so           # Still affected by -raw flag
…

If you use Windows tools to build your image, files specified as +raw won't have executable permission when the image is booted. This is because the win32 filesystem can't set a file's executable bit. To make such files executable, specify perms=+x when using +raw in the buildfile.

script attribute (boolean)

+|-script

If true, the host file is opened and processed as a script file after the process manager has initialized itself. Each line is parsed as a command line to be run. If multiple files are marked with +script, they're merged sequentially into a single file in the image filesystem; the file's name is the first script filename in the buildfile. The filenames for the subsequent script files are ignored, but they must be unique. See Script Files, below for more details on the command-line syntax.

search attribute

search=filename:filename:…

This attribute specifies that mkifs is to search for the file in the named locations on the host system. The search directory portion of the host file name isn't included in the name that's stored in the image filesystem. The default is the contents of the MKIFS_PATH environment variable.

Colon separators and forward slashes in the paths are the standard Unix conventions, but for Windows searches, you must use the standard Windows conventions, such as semicolon separators and backslashes in the paths.

type attribute

type=file_type

Set the type of the files being created in the image filesystem. Allowable types are:

link — a symbolic link
fifo — a named pipe
file — a regular, everyday file (the default)
dir — a directory

Specifying [type=dir] tells mkifs to create a directory on the target system; you don't need to specify the type when you're copying the contents of a directory. For example, to copy /usr/nto/x86/bin to /usr/bin, you a just need to specify:

/usr/bin=/usr/nto/x86/bin

uid attribute

uid=id_spec

Set the user ID number for the file. The value of this attribute may be either a number or an asterisk (*). If it's an asterisk, the user ID is taken from the host file; for an inline file, the user ID is the user running mkifs. The default value for this attribute is *.

virtual attribute

virtual=[cpu_name,]bootfile_name [filter_args]

This attribute specifies that a virtual address system is being built.

If there's a comma (,) or slash (/) in the value, the string in front of it is taken to be the CPU type of the target system. If you don't specify a CPU type, mkifs uses the host system's CPU type. The PROCESSOR environment variable is set to that string (which affects the MKIFS_PATH search path for host files).

The characters after the comma or slash (or the equal sign for the attribute if there's no comma or slash) up to the first blank character are taken to be the name of the bootfile. The suffix .boot is appended to the given name and MKIFS_PATH is searched for the file. The default bootfiles are in ${QNX_TARGET}/${PROCESSOR}/boot/sys. The bootfiles vary from one processor to another, but these are the main ones:

binary.boot: Create a simple binary image (without the jump instruction that raw.boot adds). If you build a binary image, and you want to load it with U-Boot (or some other bootloader), you have to execute mkifs -vvvv buildfile imagefile, so that you can see what the actual entry address is, and then pass that entry address to the bootloader when you start the image. If you modify the startup code, the entry address may change, so you have to obtain it every time. With a raw image, you can just have the bootloader jump to the same address that you downloaded the image to.
bios.boot: Create an image that's suitable for machines with a BIOS. Information that's gathered from the BIOS is put into the startup headers.
bios16m.boot: Don't check memory above 16 MB. Use this bootfile with older BIOSs that have trouble with such memory.
bios_nokbd.boot: Don't do anything with the keyboard controller. Use this bootfile if the BIOS doesn't properly support or emulate the legacy functionality of keyboard controllers at address 0x64.
elf.boot: Create an image that looks like an ELF executable.
nobios.boot: Create an image that's suitable for machines that don't have a BIOS.
openbios.boot: Create an image for IBM's OpenBIOS.
prepboot.boot: Create an image that boots from disk off a PREP machine.
raw.boot: Create a binary image with an instruction sequence at its beginning to jump to the offset of startup_vaddr within the startup header. The advantage is that when you download a raw image to memory using a bootloader, you can then instruct it to run right at the beginning of the image, rather than having to figure out what the actual startup_vaddr is each time you modify the startup code.
srec.boot: Create an image in S-record format.

For more details on the contents of the file, see Bootfile, below.

Any characters in the attribute value following a blank are used as arguments to any image filter command specified by the bootfile, like this:

[virtual="x86,srec -b"] boot = {

If the value of the virtual attribute includes a space, put quotation marks around the string. Otherwise, mkifs will try to interpret the value as an additional buildfile attribute placed in the same set of square brackets.

The contents of the host file that this attribute applies to are parsed to discover the bootstrap executables used to bring up the system. Each line identifies one bootstrap executable:

The first executable must be the QNX Neutrino startup executable (startup-*) that's appropriate for the target system. For more information, see startup-* .
The last must be procnto. Specifying the PATH and LD_LIBRARY_PATH environment variables before procnto sets their default values in the OS image.

Script files

As mentioned above, by specifying the [+script] attribute, you're telling mkifs that the specified file is a script file, a sequence of commands to be executed when the process manager has completed its startup.

In order to run a command, its executable must be available when the script is executed. You can add the executable to the image, or get it from a filesystem that's started before the executable is required. The latter approach results in a smaller image.

The bootfile typically sets the _CS_PATH configuration string, and might set _CS_LIBPATH. You can set environment variables, such as PATH and LD_LIBRARY_PATH, in a script file.

Script files, for the most part, look just like regular shell scripts, except that:

there are special modifiers that you can place before the actual commands to run
some commands are considered to be built-in
mkifs preparses the script file contents before placing them into the image.

The script file consists of one or more lines, with each line having the following syntax:

[modifiers] [command_line [&]]

The modifiers consist of a list, enclosed in square brackets, of blank-separated items that modify how QNX Neutrino runs the specified command_line. If there's a command line following the modifiers, the modifiers affect only that one command line. If there's no command line, the modifiers affect all subsequent command lines.

Startup scripts support foreground and background processes. Just as in the shell, specify an ampersand (&) on the command line to make the program run in the background. If you run a program in the foreground, and it doesn't exit, then the rest of the script is never executed, and the system might not become fully operational.

The modifiers are described below. Those marked as boolean accept a plus (+) or minus (-) character to enable or disable the effect; the others accept a parameter.

argv0 modifier

Sets the argv[0] element of the command argument entry. By default, this is the same as the command name. This option is typically used to simulate invoking a command via a different name; the classical example is the compress command, which can be invoked as uncompress:

[argv0=uncompress] compress filename.Z

cpu modifier

Specifies the CPU on which to launch the following process (or, if the attribute is used alone on a line without a command, sets the default CPU for all following processes). This modifier is useful for setting up bound multiprocessing (BMP). Specify the CPU as a zero-based processor number:

[cpu=0] my_program

A value of * allows the processes to run on all processors:

[cpu=*] my_program

At boot time, if there isn't a processor with the given index, a warning message is displayed, and the command is launched without any runmask restriction.

Due to a limitation in the boot image records, this syntax allows only the specification of a single CPU and not a more generic runmask. Use the on utility to spawn a process within a fully specified runmask.

external modifier (boolean)

Ordinarily, mkifs recognizes certain commands as internal commands, ones that aren't loaded from the host's filesystem, but are understood directly by mkifs. These commands are:

display_msg message: Causes the message immediately following the display_msg command to be output. This is useful during startup diagnostics; often used as a checkpoint.
procmgr_symlink: Equivalent to ln -P, except that you don't need to have ln present.
reopen [filename]: Causes standard input, standard output, and standard error to be redirected to the specified filename. Also causes the interpretation of the script file to suspend temporarily until a stat() on the specified pathname succeeds. The default filename is /dev/console.
waitfor pathname [wait_time]: Causes interpretation of the script file to suspend temporarily until a stat() on the specified pathname succeeds. Often used for synchronization, to allow a resource manager to perform its startup functionality, and then for the process manager to proceed with the further interpretation of the script file.
The optional wait_time specifies the maximum number of seconds to wait for the file to appear. It can include one decimal place to specify tenths of a second. The default is 5.0 seconds.

The +external modifier instructs mkifs to search for the specified command on the host filesystem, rather than assume the internal meaning for the command. The default is -external.

Using +external is a dubious practice. Specifying an external modifier on a command that isn't an internal command is redundant.

pri modifier

Lets you specify the command's priority and optionally the scheduling policy. The pri modifier accepts a numeric priority, optionally followed by one of the letters:

f: FIFO scheduling policy.
r: Round-robin scheduling policy.
o: Other scheduling policy (currently maps to round-robin).

See the System Architecture guide for a description of the various priority levels and scheduling algorithms.

The default priority and policy are specified by procnto , and could change in future versions of QNX Neutrino. If the priority and scheduling policy of the processes are important to you, be sure to use the pri= modifier.

session modifier (boolean)

If +session is specified, make the process a session leader (as per POSIX), and make the process's stdin the controlling terminal (i.e. direct Ctrl C at this process group). If -session is specified, don't make the process a session leader. The default is -session.

This parameter is typically used for the shell:

[+session] esh

Bootfile

When building a bootable filesystem, you must specify a bootfile via the physical or virtual attribute. Note that the bootfile must be the first file specification within the buildfile. If the first character of the bootfile is a left square bracket ([), a list of configuration attributes is given in the same syntax as the buildfile. The list of attributes is terminated by a right square bracket (]). The allowed attributes, and their formats, are:

attr= image_attribute

Specify an attribute to add to the image. These attributes are processed after the -l (el) command-line options and the buildfile, but you normally use the ? prefix on the image_attribute, so that it doesn't override anything explicitly set by the -l option or the buildfile.

+|-big_pages

Align binaries and shared libraries at the appropriate address, based on the size of the UIP text and the sizes specified by the pagesizes attribute. You can specify these attributes in the buildfile or in the bootfile. For more information, see the big_pages buildfile attribute.

default_image= addr_space_spec

Set the defaults for the image file attribute (see above).

default_ram= addr_space_spec

Set the defaults for the ram file attribute (see above).

filter= image_filter_spec

After the image has been created, run image_filter_spec. The following formatting codes are expanded:

%i — the name of the output image file.
%I (uppercase i) — the name of the input file (see below).
%s — the offset of the startup header in the image file, in hex with a leading 0x.
%a — any arguments from the physical or virtual attribute.

See Image filter, below for an example of using the image_filter_spec.

len= boot_length

The boot_length parameter gives the amount of space to leave at the front of the image file (before the actual image filesystem) for system header information or boot prefix code. This is the minimum amount of space to reserve. If the boot prefix code following the bootfile attributes is larger than the number given here, the size of the boot prefix code is used instead. The default is zero.

notloaded= length

In some systems (such as IBM OpenBIOS), the system header information isn't loaded into memory and doesn't contribute to the memory offsets where things are placed (the base address of the image being set by the image attribute in the buildfile). This attribute specifies the size of the information that isn't going to be loaded into memory. The default is zero.

paddr_bias= number

On some CPUs (such as MIPS), the hardware reserves a range of virtual addresses that map one-to-one with physical address. This attribute lets mkifs know how to translate a virtual address to its physical location in memory via the formula:

    phys_addr = virt_addr + number

The default is zero.

pagesize= size

Set the size of a page in the image filesystem. The mkifs utility aligns various structures to a multiple of this. The default is 4 KB.

pagesizes= size[,size]...

Define the page sizes for use with the big_pages attribute. You can specify these attributes in the buildfile or in the bootfile. For more information, see the pagesizes buildfile attribute.

vboot= addr

When building a virtual system, the paging hardware is sometimes turned on by the startup code (e.g. x86 architecture), as opposed to procnto (e.g. MIPS architecture). In the first case, this option tells mkifs what base virtual address to use for the bootstrap executables. This option has no effect when building a physical system. The default is none.

Following the closing square bracket character (]) of the bootfile attributes, mkifs searches for the string boot. If it's found, mkifs considers all data immediately following, through to the end of the file, to be boot prefix code. This data is placed at the start of the image file. If the len attribute was specified and is larger than the size of the boot prefix code, the image file is padded out to the size given.

Image filter

You can specify an image filter within the specification for the bootfile, and optionally specify macro expansions to it. These macro expansions are documented above, in the filter description.

The following image filters are currently available:

mkifsf_elf

Wrap the entire image in an ELF section.

mkifsf_openbios

Patch the header at the beginning of the image for IBM's OpenBIOS.

mkifsf_srec

Convert the image into S-Record format. This filter accepts the following options:

-b — generate only 4-byte address records.
-c — omit the carriage-return character at the ends of lines.
-l — omit the linefeed character at the ends of lines.

Generally, image filters are expected to take the file specified by the %i variable and modify it in place. If this isn't possible (e.g. the file changes size as a result of the filter program), specifying %I causes mkifs to store the original file in a temporary filename (named by %I), and expect the modified file in the filename given by %i. This happens only when the %I macro expansion is specified.

Linker specification

The linker specification lets you control how the linker command line is built when mkifs needs to turn a relocatable object into an executable running at a particular address. It operates much like a printf() format string, with characters being copied from the format to the command line until a percent character (%) is found. The following formatting codes after a percent character are supported:

%h

The address to place the executable header at, in hexadecimal.

%t

The address to place the text segment at, in hexadecimal. This is %h plus the amount of space for the executable header structures.

%d

The address to place the data segment at, in hexadecimal. This value may be zero, in which case the data is placed immediately following the text segment.

%o

The name of the output executable file, as a string.

%i

The name of the input relocatable file, as a string.

%(

Open a conditional section. Following the opening parenthesis, (, are: a single character indicating the variable that the section is conditional on; one of the usual conditional operators from the C language; a constant; and finally a comma.

The contents of the variable are compared against the constant and if the result is true, the text following the comma is included in the command string being built. If the comparison is false, the contents of the string following the comma are omitted.

The conditional is terminated by percent character followed by a closing parenthesis, %). You can nest conditionals. The variables that you can test are:

Variable:	Value:
e	0 == little endian 1 == big endian
d	Data segment address
f	0 == startup file 1 == bootstrap file 2 == normal file
h	Executable header address
m	Machine number from the ELF header
v	0 == file linked physically 1 == file linked virtually
V	0 == physical system 1 == virtual system

%)

Terminate a conditional section.

Here's the default linker command specification for mkifs:

static char default_linker[] = {
        "qcc"
        " -bootstrap -nostdlib -Wl,--no-keep-memory -Vgcc_nto"
        "%(m==3,x86%)%(m==6,x86%)"
        "%(m==8,mips%)"
        "%(m==20,ppc%)"
        "%(m==40,arm%)"
        "%(m==42,sh%)"
        "%(m!=3,%(m!=6,%(e==0, -EL%)%(e==1, -EB%)%)%)"
        "%(h!=0, -Wl,-Ttext -Wl,0x%t%)%(d!=0, -Wl,-Tdata -Wl,0x%d%)"
        " -o%o %i"
        "%[M -L%^i -Wl,-uinit_%n -lmod_%n%]"
};

For the meaning of the parameters specified, see gcc .

Output image format

The image created by mkifs has the following layout:

Figure showing output image layout.

The boot prefix is generated based on the bootfile that you specified with the virtual= or physical= attribute.
The boot prefix, startup header, startup, and startup trailer are present only in a bootable image.
A checksum for the startup information is stored in the startup trailer.
A checksum for the image is stored in the image trailer.

Although it isn't necessary to have a detailed understanding of the format of an image to make one, a general understanding is worthwhile.

Boot prefix

The first section (called the boot prefix) is controlled by the bootfile that you specified in the virtual= or physical= attribute. For many systems this section doesn't occupy any space in the image. When it's present, it's typically used to address one of the following issues:

The IPL code that transfers control to the image doesn't set up the processor state in a way that's compatible with startup. In this case, this section contains code that does that work. If you've written your own IPL, it ensures the processor is in a suitable state before jumping to startup, and this section is empty.
A boot on a standard x86 PC is a good example of the need for placing code here. When a PC boots, it transfers control while in 16-bit real mode. The startup program assumes the processor is running in 32-bit protected mode. So, an image with a PC BIOS boot contains code here that switches the processor into 32-bit protected mode. It also does a series of BIOS calls to gather information from the BIOS, since the protected mode startup program is unable to make any BIOS calls itself.
The image is wrapped or encapsulated within another data structure used by an IPL. To ensure proper alignment of executables on page boundaries, mkifs needs to know how large the wrapper is at the beginning of the image. In this case, mkifs creates a zero-filled region for the boot prefix, which an external program (the image filter) modifies as a post-processing pass over the image.
An example of this is a network boot in which the image needs to be wrapped in something that was loaded in its entirety into memory on the target (e.g. ELF object file structures). In this case, an external program makes a copy of the image, adding information to the front, and possibly the end, of the image. If the wrapper prefix is a small fixed size, you may wish to include a boot prefix that's zero-filled, which an external program can overwrite. This saves you having to make a file copy of a large image to append to the wrapper. You can always append a wrapper directly to the end of an image file.

Startup header

This section contains information about the image, which is used by our IPL and startup programs.

Part of this section is written to by mkifs. Another part is set to zero, and is written to by the IPL code to pass data (determined at runtime) to startup.

If an image isn't bootable, this section is omitted.

Startup

This section contains the code and data for the startup program. This code must be executed in RAM. If the image is in ROM/FLASH, our standard IPL code uses information in the startup header to always copy the startup into RAM and transfer control to it there.

If an image isn't bootable, this section is omitted.

Startup trailer

A checksum for use by startup. If an image isn't bootable, this section is omitted.

Image header

Information on the image filesystem that follows.

Image directory

A series of directory entries for each file in the image filesystem.

Files

The files within the image filesystem. Executables that are executed in place are aligned on page boundaries. An attempt is made to fill any holes created by this alignment with small data files that have no alignment needs.

Image trailer

A checksum for the image.

Notes on XIP versus copy

You can apply the code=copy|uip and data=copy|uip attributes to executables in the image.

Shared objects currently assume code=uip and data=copy. To get the effect of code=copy, manually copy the shared object to /dev/shmem and set LD_LIBRARY_PATH as appropriate. To save ROM/Flash space, compress the shared object in the image filesystem and decompress it into /dev/shmem.

When an executable is run, these attributes determine whether the code or data for that executable is to be used in place or copied to RAM. An image filesystem may exist in either RAM or linearly addressable ROM/FLASH. Images in RAM are usually loaded from a device that isn't linearly addressable. This includes disk boots, network boots, and boots from bank-switched ROM/FLASH devices. It also includes any image that's been compressed.

For example, a compressed image may reside in linearly addressable flash, but it can't be used until it's decompressed into RAM. The following combinations exist for any image in RAM:

Code	Data	Comments
uip	uip	Run once (default)
uip	copy	Run multiple
copy	uip	Run once but wasteful
copy	copy	Run multiple but wasteful

The default assumes that you want to run both code and data in place. This would be fine for an executable that has a large amount of static data and that you need to run only once (e.g. a resource manager or driver that starts when the system boots). Running data in place modifies the only copy of the data as the program runs, so you can't start the program again.

In this case, the file's sticky bit won't be set. This identifies the executable to the QNX Neutrino process manager, which will prevent the program from running more than once, thus avoiding the possibility of running a program with corrupted static data.

That's why you have to specify data=copy if you want to run the executable multiple times.

The two cases listed as wasteful fall out of the combinations but they provide no additional capabilities and waste memory by copying the code unnecessarily. Since the code is read-only and can't be modified, it can always be used in place.

If you're creating an image in ROM/FLASH, the following combinations exist:

Code	Data	Comments
uip	uip	Run once
uip	copy	Run multiple (default)
copy	uip	Run once
copy	copy	Run multiple (slow ROM/FLASH)

You have to specify both image and ram file attributes if you want to create the image in ROM/FLASH; otherwise the process manager assumes that the image is in RAM. The data=copy attribute is assumed for an image in ROM/Flash.

The cases where code is copied may seem wasteful (as in the RAM image example) but it may make sense for systems where the ROM/FLASH is slow — perhaps it has an 8-bit interface or requires extra wait states for access to it. In that case, you may wish to copy it to RAM, so that it executes faster.

Examples:

Here's a very simple buildfile that specifies the operating system, a console driver, and a shell:

[virtual=x86,bios] .bootstrap = {
    startup-bios
    PATH=/proc/boot procnto
}

[+script] .script = {
    devc-con -n9 &
    reopen /dev/con1
    [+session] esh &
}
libc.so
[data=copy]
devc-con
esh
[type=link] /usr/lib/ldqnx.so.2=/proc/boot/libc.so

The runtime linker is expected to be found in a file called ldqnx.so.2, but the runtime linker is currently contained within the libc.so file, so we make a process-manager symbolic link to it.

For MIPS targets, you need to name this link ldqnx.so.3 instead of ldqnx.so.2.

You can now build an image from the above, like this (assuming that the buildfile is called simple.bld, and that we want the resultant image to be called simple.ifs):

mkifs simple.bld simple.ifs

Here's a buildfile with EIDE disk support:

[virtual=x86,bios +compress] .bootstrap = {
    startup-bios
    PATH=/proc/boot procnto
}
[+script] .script = {
    devc-con -e &
    devb-eide &
    reopen /dev/con1
    [+session] PATH=/proc/boot esh &
}
libc.so
libcam.so
cam-disk.so
io-blk.so
fs-qnx4.so

[data=copy]
devc-con
esh
ls
devb-eide
[type=link] /usr/lib/ldqnx.so.2=/proc/boot/libc.so.3

The following example includes an inline /etc/hosts file that's used to resolve addresses used at boot time by programs such as fs-nfs3; it also shows how you can pass environment variables to different commands:

In a real buildfile, you can't use a backslash (\) to break a long line into shorter pieces, but we've done that here, just to make the buildfile easier to read.

[image=0x1f0000]
[virtual=ppcbe,raw] .bootstrap = {
    startup-mtx604-smp -v -Nmtx604-5 -D0x800003f8^0.9600
    PATH=/proc/boot:/bin:/usr/bin:/sbin:/usr/sbin \
LD_LIBRARY_PATH=/proc/boot:/lib:/usr/lib:/lib/dll \
procnto-600-smp -v
}

[+script] startup-script = {
    # To save memory, make everyone use the libc in the boot
    # image! For speed (fewer symbolic lookups), we point to
    # libc.so.3 instead of libc.so.

    procmgr_symlink ../../proc/boot/libc.so.3 /usr/lib/ldqnx.so.2

    pci-raven &
    waitfor /dev/pci

    io-pkt-v4 -dtulip irq=2,media=9,vid=0x1011,did=0x9 -ptcpip &
    if_up -p en0
    ifconfig en0 mtx604-5 up
    if_up en0

    fs-nfs3 -ru ra:/my_system /my_system &
    waitfor /my_system/target/qnx6/ppcbe/usr/sbin/slogger 360

    # setup environment variables
    TZ=est05edt04

    procmgr_symlink /my_system/target/qnx6/ppcbe/bin /bin
    procmgr_symlink /my_system/target/qnx6/ppcbe/lib /lib
    procmgr_symlink /my_system/target/qnx6/ppcbe/sbin /sbin
    procmgr_symlink /my_system/target/qnx6/ppcbe/usr/bin /usr/bin
    procmgr_symlink /my_system/target/qnx6/ppcbe/usr/sbin /usr/sbin
    procmgr_symlink /my_system/target/qnx6/ppcbe/usr/lib /usr/lib
    procmgr_symlink /my_system/target/qnx6/etc /etc

    slogger &
    waitfor /dev/slog
    devc-ser8250 -e -c1846200 -b 9600 0x800003f8,104 0x800002f8,103 &
    waitfor /dev/ser1
    pipe &
    waitfor /dev/pipe
    devc-pty &
    waitfor /dev/ptyp0
    mqueue &
    inetd &

    tinit
}

[type=link] /tmp = /dev/shmem
[type=link] /dev/con1 = /dev/ser1

# Data files are created in the named directory
/etc/hosts = {
127.0.0.1       localhost
192.168.1.1     ra
192.168.1.111   mtx604-5
}

# Include the current libc.so. It will be created as a real
# file using its internal SONAME, with libc.so being a
# symlink to it. The symlink will point to the last libc.so.*,
# so if an earlier libc is needed (e.g. libc.so.2), add it
# before libc.so.

libc.so.2
libc.so
devn-tulip.so
libsocket.so

[data=uip]
pci-raven
io-pkt-v4

[data=copy]
if_up
ifconfig
fs-nfs3

For more examples, see ${QNX_TARGET}/${PROCESSOR}/build.

Environment variables:

PROCESSOR

Specifies the target CPU. If not set, the default is the same as the CPU of the host system (e.g. x86).

MKIFS_PATH

Specifies a colon-separated list of directories to search for host files that to be included in the image. The default value consists of:

The current working directory, if the filename contains a slash (/) but doesn't start with a slash.
${QNX_TARGET}/${PROCESSOR}/sbin
${QNX_TARGET}/${PROCESSOR}/usr/sbin
${QNX_TARGET}/${PROCESSOR}/boot/sys
${QNX_TARGET}/${PROCESSOR}/bin
${QNX_TARGET}/${PROCESSOR}/usr/bin
${QNX_TARGET}/${PROCESSOR}/lib
${QNX_TARGET}/${PROCESSOR}/lib/dll
${QNX_TARGET}/${PROCESSOR}/usr/lib
${QNX_TARGET}/${PROCESSOR}/usr/photon/bin

Exit status:

0: Successful completion.
1: An error occurred.

mkifs

Syntax:

Options:

Description:

Examples:

Environment variables:

Exit status:

Related links

BBM Channels