From owner-freebsd-small@FreeBSD.ORG Thu May 25 11:24:28 2006 Return-Path: X-Original-To: small@freebsd.org Delivered-To: freebsd-small@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8444516A43B; Thu, 25 May 2006 11:24:28 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id F138C43D78; Thu, 25 May 2006 11:24:19 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x50a07cfc.naenxx7.adsl-dhcp.tele.dk [80.160.124.252]) by pfepa.post.tele.dk (Postfix) with ESMTP id C7DC8FAC04B; Thu, 25 May 2006 13:24:15 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.6/8.13.6) with ESMTP id k4PBODVI002539; Thu, 25 May 2006 13:24:13 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: small@freebsd.org, current@freebsd.org From: Poul-Henning Kamp Date: Thu, 25 May 2006 13:24:13 +0200 Message-ID: <2538.1148556253@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: FreeBSD's embedded agenda X-BeenThere: freebsd-small@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 11:24:32 -0000 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@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@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.