FreeBSD's embedded agenda

[Poul-Henning Kamp]

FreeBSD is a great operating system for embedded use and people all over
the world use this to their advantage.

At the developer summit in Ottawa this month (right before the
wonderful BSDcan conference) we spent a lot of time talking about
what we as developers can do to further this market segment.

In FreeBSD we operate very much on the IETFs (now disused ?) principle
of "Rough concensus and running code", so rather than a party approved
five year plan with explanatory footnotes with obligatory powerpoint,
you get this email from me to tell you what to expect in the future.

In other words, this email carries little weight in the big scheme
of things, but with a little luck, it might could just be how things
turn out.

Overall Focus
-------------

I think we found three main areas where we need to do some work:
platforms, packaging and evangelism.


Platforms
---------

I386 goes without saying.

AMD64 may have an embedded future in the high end segment, keeping
it "unbloated" is a concern.

ARM is going great according to Jean-Mark and Warner, and we are
looking for a cheap (< $200) reference platform to point people at.

MIPS is a desirable target, and it was generally agreed that it
should "Just Be Done" but it's anybodys guess if that turns into
somebody "Just Did It".

PPC is also interesting and some users talked about having something
to contribute in this area, but again, it hasn't happened and we
do not know if it will.


Packing up FreeBSD
------------------

We think that it is important to make it easy for people to get
FreeBSD onto their embedded hardware so that they can start
their work by experimenting and customizing rather than figuring
out how to get FreeBSD to boot at all.

Currently FreeBSD comes in three different packagings:

    * The official release	"Normal disk installations"
    * The FreeSBIE kit		"Run from CDROM etc"
    * NanoBSD			"Run from flash etc"

The official release is not really relevant in this context.

FreeSBIE is interesting in the upper size of embedded systems,
and it is gaining flexibility and features fast.  If you have
rotating media available, FreeSBIE is probably what you should
look at.

NanoBSD caters only to the "run read-only from flash" area, call
it if you will the "soekris" area.  I need to investigate if it
makes sense to use the FreeSBIE framework to build nanobsd images.

It was generally agreed that we lacked a framework for doing really
small systems.  NanoBSD uses a subtractive approach ("WITOUT_THIS,
WITHOUT_THAT etc") and this breaks down below 32-64 MB storage.

For smaller systems, an additive approach would make more sense
("I want /bin/sh, /bin/ls ...") where the framework would do the
nasty work of figuring out dependencies (necessary libraries and
other files) and most of all, issue a comprehensive report that
tells why a particular file was necessary ("/usr/share/termpcap
is necessary because of /usr/bin/top").

For now it seems that everybody who works in this "really small"
area do their own thing, and nobody directly volunteered to try
to do a framework for this kind of thing.

An important footnote in this area is that we need to exploit the
new generalized WITH_FOO/WITHOUT_FOO build framework to make life
easier for embedded systems when new major feature sets come in.
I intend to maintain the build-option survey to help with this.


Advocacy
--------

Right now we do nearly nothing.

For our "reference platforms" we need two part webpages.

The first half: "to get FreeBSD running on this kit, download
this and do that", with pictures, arrows and config file lines etc.

The second half: "Here is how to build this image on your own"

We also need white-papers, HOW-TO's, magazine articles and so on.

Nobody really owned up to any of this.

We did however agree that we have the small@ mailing list and that
we should use it more (Therefore this email).


Conclusion
----------

So, what's the difference ?

Good question.

At this point mainly an increased awareness on our part that there
are (many) people out there using FreeBSD for embedded work and
that we should try to generalize our individual hacks to give people
something start from.

What can you do ?

If you work with embedded FreeBSD, I think the best you can do is to
chime in to small at freebsd.org, tell us what you are doing (as far as
company policy will allow you), and if you have any ideas, wishes,
problems, let us hear about them.

It would be great if we could park a couple of developers full time
on embedded FreeBSD in the future, but that would take some serious
financial support from the user community, if you think your company
could be persuaded to help with this, get in touch with the FreeBSD
foundation.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.