Complete example — TCP/IP with network filesystem

Here's an example of a buildfile that starts up an Ethernet driver, the TCP/IP stack, and the network filesystem:

[virtual=armle,elf +compress] .bootstrap = {
  startup-abc123 -vvv
  PATH=/proc/boot procnto
}
[+script] .script = {
    devc-ser8250 -e -b9600 0x1d0003f8,0x23 &
    reopen

#  Start the PCI server
   pci-abc123 &
   waitfor /dev/pci

#  Network drivers and filesystems

    io-pkt-v4 -dtulip-abc123 name=en
    if_up -p en0
    ifconfig en0 10.0.0.1

    fs-nfs3 10.0.0.2:/armle/ / 10.0.0.2:/etc /etc &
#  Wait for a "bin" for the rest of the commands
    waitfor /usr/bin

# Some common servers
    pipe &
    mqueue &
    devc-pty &

    [+session] sh &
}

# make /tmp point to the shared memory area
[type=link] /tmp=/dev/shmem

# Redirect console messages
[type=link] /dev/console=/dev/ser1

# Programs require the runtime linker (ldqnx.so) to be at
# a fixed location
[type=link] /usr/lib/ldqnx.so.2=/proc/boot/libc.so
# We use the C shared lib (which also contains the runtime linker)
libc.so

# If someone needs floating point...
fpemu.so.2

# Include the network files so we can access files across the net
devn-tulip-abc123.so

# Include the socket library
libsocket.so
[data=copy]

# Include the network executables.
devc-ser8250
io-pkt-v4
fs-nfs3
Note: For this release of Neutrino, you can't use the floating-point emulator (fpemu.so.2) in statically linked executables.

This buildfile is very similar to the previous one shown for the disk. The major difference is that instead of starting devb-eide to get a disk filesystem driver running, we started io-pkt-v4 to get the network drivers running. The -d specifies the driver that should be loaded, in this case the driver for a DEC 21x4x (Tulip)-compatible Ethernet controller.

Once the network manager is running, we need to synchronize the script file interpretation to the availability of the drivers. That's what the waitfor /dev/socket is for — it waits for the network manager to initialize itself. The ifconfig en0 10.0.0.1 command then specifies the IP address of the interface.

The next thing started is the NFS filesystem module, fs-nfs3, with options telling it that it should mount the filesystem present on 10.0.0.2 in two different places: ${QNX_TARGET} should be mounted in /, and /etc should be mounted as /etc.

Since it may take some time to go over the network and establish the mounting, we see another waitfor, this time ensuring that the filesystem on the remote has been correctly mounted (here we assume that the remote has a directory called ${QNX_TARGET}/armle/bin — since we've mounted the remote's ${QNX_TARGET} as /, the waitfor is really waiting for armle/bin under the remote's ${QNX_TARGET} to show up).