SDK Generator

SDK Userspace NFS Use Scenarios and Workflow

Scenario 1: Minimal installation using meta-toolchain with a QEMU SDK image

Sally is an embedded application developer who works for a large corporation which locks-down its developer workstations and does not allow developers root access. :(

Sally's System Administrator set up her workstation for Poky development by doing the following:

1. Extracting the output from a meta-toolchain build (poky-glibc-x86_64-i586-toolchain-XYZ.tar.bz2) into /opt/poky
2. Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
3. Run the poky-qemu-ifup command N times to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Sally is a member of.

Sally then sources the meta-toolchain environment file (source /opt/poky/environment-setup-i586-poky-linux), which adds the toolchain's usr/bin directory into her $PATH and sets some other build-related environment variables.

She then downloads a poky-image-sdk tarball and a QEMU kernel. Sally can copy the kernel and extract the SDK image tarball to an arbitrary work area, but she must extract the SDK image tarball using the following script:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

The documentation may recommend standard directories (e.g, ~/qemukernels/<kernel> ~/rootfs/<machinetype>), but Sally is free to choose another directory if that suits her needs better.

She then can run QEMU to automatically boot to this nfsroot with the following command:

runqemu-nfs {machine-type} <kernel> <rootfs-dir>

Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from /opt/poky and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/

It would then start up QEMU with the next available tap network device and mount its rootfs.

When Sally shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Sally could also forcefully shut down the NFS server and networking with the following command:

poky-export-rootfs stop <path to rootfs>

Scenario 2: In-tree Poky setup with a QEMU SDK image

Roger is an embedded developer who, like Sally, works for a large corporation which locks-down its developer workstations and does not allow developers root access. :(

Roger's System Administrator sets up his workstation for Poky development by doing the following:

1. Install and ensure that rpcbind or portmap is running (note: rpcbind requires an insecure option, -i to work)
2. Run the poky-qemu-ifup command N times to create a bank of tun devices that can be used by QEMU networking. These devices are owned by a group that Roger is a member of.

Thus, the only difference is that Roger doesn't need the cross-toolchain installed in /opt/poky. That is because Roger is willing to do full Poky builds, and has the Poky tarball extracted in some area he prefers to work (e.g, ~/poky).

Roger sources the poky-init-build-env script, which sets up his environment for Poky builds. He then bitbakes a poky-image-sdk image, which creates a qemu kernel and SDK image tarball in his ~/poky/build/tmp/deploy/images/ directory.

Roger then extracts the SDK image tarball with:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

and then starts QEMU to boot to this using:

runqemu-nfs {machine-type} <kernel> <rootfs-dir>

Where machine-type is optional if the kernel is named according to poky conventions (e.g, bzImage-qemux86.bin). This script would automatically start up the userspace NFS server using binaries from the automatically detected Poky native sysroot and create runtime files (such as exports, rmtab, *.pid files, and so on) in ~/.poky-sdk/

It would then start up QEMU with the next available tap network device and mount its rootfs.

When Roger shuts down the QEMU session (either gracefully or by simply killing it), the userspace NFS server would be shut down and the tap network device released automatically. Roger could also forcefully shut down the NFS server and networking with the following command:

poky-export-rootfs stop <path to rootfs>

Scenario 3: Exporting a rootfs to a non-QEMU target

This allows developers to export a rootfs to non-qemu targets (i.e, real hardware).

First, the rootfs must be created using the poky-extract-sdk script, which creates the filesystem tree using pseudo:

poky-extract-sdk <poky-sdk-tarball> <extract-dir>

Then they can start/stop/restart the unfs server with:

poky-export-rootfs {start|stop|restart} <path to rootfs>

The developer would then configure their hardware to boot using a kernel accessed over tftp and with a rootfs pointed at the hosts's IP and exported directory.