- 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 i386, sparc64, arm, amd64, powerpc, ia64 and 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) upto-date or close to upto-date. - Tracking security vulnerabilities is straightforward on FreeBSD, both for the base system and for 3rd-party ports.
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 slipup 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'd like an image from the RELENG_6 branch suitable for a Linksys WRT54GS clone, with pf and sshd from the base system, and clamav and smtp-proxy from 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 gprof on an AMD64 platform to analyse profiles for ARM binaries. 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 that the default).
- Documentation on scaling FreeBSD down would be useful to new adopters. Right now this knowledge is scattered in our list archives.
No comments:
Post a Comment