From owner-freebsd-small@FreeBSD.ORG Tue May 16 03:52:47 2006 Return-Path: X-Original-To: freebsd-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 72FB216A42C for ; Tue, 16 May 2006 03:52:47 +0000 (UTC) (envelope-from brucem@mail.cruzio.com) Received: from cruzio.com (dsl-63-249-85-132.cruzio.com [63.249.85.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C2B743D45 for ; Tue, 16 May 2006 03:52:47 +0000 (GMT) (envelope-from brucem@mail.cruzio.com) Received: from mail.cruzio.com (localhost [127.0.0.1]) by cruzio.com (8.12.10/8.12.10) with ESMTP id k4G3tpXB000381 for ; Mon, 15 May 2006 20:55:51 -0700 (PDT) (envelope-from brucem@mail.cruzio.com) Received: (from brucem@localhost) by mail.cruzio.com (8.12.10/8.12.10/Submit) id k4G3tp5f000380 for freebsd-small@freebsd.org; Mon, 15 May 2006 20:55:51 -0700 (PDT) (envelope-from brucem) Date: Mon, 15 May 2006 20:55:51 -0700 (PDT) From: "Bruce R. Montague" Message-Id: <200605160355.k4G3tp5f000380@mail.cruzio.com> To: freebsd-small@freebsd.org Subject: Re: Embedded FreeBSD Presentation... 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: Tue, 16 May 2006 03:52:47 -0000 Hi... re small/embedded/pre-built FreeBSD, the recent Intel VT and AMD Pacifica technology might resurect interest in "smallish"/self-contained FreeBSD systems (such as all those targeted at the embedded space, including picobsd). The VT hardware effectively makes it possible to implement virtual machines with overheads down below 5% or so (that is, VT is hardware virtual machine assist; essentially it adds the stuff IBM knew/learned about making mainframe virtual machine systems back in the late 60's to the modern x86 architecture). With such VM support, it's often convenient to have small systems... Although it's slightly orthogonal to classic embedded systems, one motivating concept pushing the adaption of VT is that virtual machines will become the basic components of distributed systems and software distribution. Instead of buying/downloading and installing an application, a VM containing an entire "software stack" will be obtained, ready to run. All needed libraries, suite of applications, kernel configs, etc., are set up ready to go. Of course you need virtual LANs on your host to link up all your VMs. Once you really have VMs working, its fairly easy to checkpoint/restore complete running systems (over any span of time) and then to migrate VMs between physical hosts. In this model one can think of a "mobile application" as being an application "wrapped" with a cut-down version of it's most natural OS, perhaps in "already running" state. To make virtual machine migration work, it's best to have the entire VM image small. Thus having small versions of FreeBSD that can be used to populate (hopefully lightweight) VMs that host (perhaps only) a single application might be useful. See Stanford's work on "virtual appliances" (VmWare calls this concept "network appliances".) "Appliance" is perhaps not the best name. A lot of the excitement about Xen results because it can do live migration between nodes of a subnet of a VM running Linx and an Apache server, with something like only 200 milliseconds of unavailability perceived wrt the server. (This was with para-virtualized OSes (that is, guts rewritten), but the VT hardware should enable this to be done with unmodified guest OSes.) Live migration works by having one hypervisor talk to another and moving dirtied pages from one to another faster than they dirty on the source, so the VM ends up moving over the network while its applications remain running. = bruce