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 filesystem. The major difference is that instead of starting devb-eide to get a disk filesystem driver running, we start io-pkt-v6-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=aarch64le,elf +compress] .bootstrap = {
	startup-abc123 -vvv
	PATH=/proc/boot procnto

[+script] .script = {
	devc-ser8250 -e -b9600 0x1d0003f8,0x23 &

	waitfor /dev/ser1 4

	reopen /dev/ser1

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

#	Network drivers and filesystems
	io-pkt-v6-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
	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, the runtime linker,
# and GGC's low-level runtime library

# Network driver
display_msg starting Network driver...
io-pkt-v6-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 makes the interpretation 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 as /, and /etc should be mounted as /etc.

It may take some time to go over the network and establish the mounting, so we issue another waitfor, this time ensuring that the filesystem on the remote system has been correctly mounted. We assume that the remote system has a directory called ${QNX_TARGET}/aarch64le/bin — since we've mounted the remote's ${QNX_TARGET} as /, the waitfor is really waiting for aarch64le/bin under the remote's ${QNX_TARGET} to show up.