The past few weeks I have been hacking a small MIPS™-based router, getting a glimpse into the workings of the embedded ‘Linux’ world. This is life at the edge of chaos: open-source, yes, but nearly bereft of sane software development practices. The FreeBSD™ world is so much nicer:
I found FreeBSD to be an excellent platform for development. The tools I needed were already part of the FreeBSD ports collection, and building applications via ports allowed me to tweak their configuration as I wished (e.g.,
make WITH_PYTHON=1 WITHOUT_PERL=1); a future port upgrade would preserve such settings automatically. User interaction remains smooth and glitch-free even running large compiles in the background.
Cross-development in FreeBSD is straightforward to get started off with …
# cd /usr/src # make buildworld TARGET_ARCH=other-architecture # make buildenv TARGET_ARCH=other-architecture
and in one fell swoop one has a cross-compiler, standard libraries, and all the standard utilities synchronized with the kernel and ready for use. This is very different from the typical ‘Linux’ project where one has to do a lot of work to reach this point.
Then there is source history for every file in the base system. Figuring out “what changed?” isn’t an exercise in frustration, scanning a myriad diffs and rummaging inside terse changelogs.
Similarly, is no need to go hunting on the ‘net for the current version of common utilities, hoping that these would work with today’s cross-toolchain and patch set. Most of the common utilities that one needs for an embedded product are part of our base system—code and have recieved a fair degree of testing on our supported architectures, the
alpha. For 3rd-party tools too, patch management is easy with FreeBSD: if a FreeBSD port exists for the application then a
# cd PORTS-DIR && make patch
would give you source code that is (a) patched to compile on FreeBSD and is (b) up to date or close to up to date.
Tracking security vulnerabilities is straightforward on FreeBSD, both for the base system and for 3rd-party ports.
It was sobering to realize how much we FreeBSD folk just take for granted.
I also now understand how embedded Linux vendor companies manage to charge hefty sums for their embedded OS offerings. If I were a manager charged with implementing an ‘embedded’ Linux device, I would pay too. The risk of a project slip-up because of some bizarre interaction between lightly tested upstream source bases is all too real here.
There are a number of ways by which FreeBSD could be made even better for embedded development:
It would be great if we could cross-compile 3rd-party applications as easily as we do the base system today. A general fix is probably hard, but there are ways to get the near ubiquitous “
configure” shell script to handle cross builds reasonably well.
We need a way to quickly cobble together complete system images (kernel, configuration files, basic utilities, 3rd party tools) for common target platforms. For example, what if we could say:
I would like an image from the
RELENG_6branch suitable for a Linksys WRT54GS clone, with
sshdfrom the base system, and
smtp-proxyfrom ports and with the following local patches …
and have the system churn out a flashable image? The NanoBSD and PicoBSD tools are a start in this direction.
We need our system analysis and performance measurement tools to be truly cross-platform and embedded development friendly. For example, it would be cool to be able to run
AMD64platform to analyse profiles for
ARMbinaries. It would be useful to be able to take kernel core dumps over the network and have seamless cross-architecture kernel debugging over a local LAN.
Multiple implementations of system functionality would be useful (e.g., some embedded applications could benefit from a less profilgate
malloc(3)implementation than the default).
Documentation on scaling FreeBSD down would be useful to new adopters. Right now this knowledge is scattered in our list archives.
It would be great to see FreeBSD running on more embedded & resource constrained platforms.