TCP/IP with network filesystem

This buildfile starts up an Ethernet driver, the TCP/IP stack, and the network filesystem.

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-hc to get the network drivers running. The -d specifies the driver that should be loaded, in this case the driver for a fictional Horatio Ethernet controller:

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

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

#	Network drivers and filesystems
	io-pkt-v4-hc -dhoratio-abc123 name=en
	if_up -p en0
	ifconfig en0

	fs-nfs3 / /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 ( to be at
# a fixed location
[type=link] /usr/lib/
# We use the C shared lib (which also contains the runtime linker)

# Network driver
display_msg starting Network driver...
io-pkt-v4-hc -ddm814x-am437x deviceindex=0

waitfor /dev/socket 4

# Include the network files so we can access files across the net

# Include the socket library

# Include the network executables.
Note: For this release of the QNX Neutrino RTOS, you can't use the floating-point emulator ( in statically linked executables.

Once the network manager is running, we need to synchronize the script file interpretation to the availability of the drivers. The waitfor /dev/socket obliges the interpretation to wait for the network manager to initialize itself. When the network manager has The ifconfig en0 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 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-v8/bin — since we've mounted the remote's ${QNX_TARGET} as /, the waitfor is really waiting for armle-v8/bin under the remote's ${QNX_TARGET} to show up).