From owner-freebsd-small@FreeBSD.ORG Tue May 30 22:57:15 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 B65F616B3B6 for ; Tue, 30 May 2006 22:57:15 +0000 (UTC) (envelope-from jim@netgate.com) Received: from netgate.com (mail.netgate.com [64.62.194.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E9F843D48 for ; Tue, 30 May 2006 22:57:15 +0000 (GMT) (envelope-from jim@netgate.com) Received: from [192.168.2.184] (rrcs-67-52-77-54.west.biz.rr.com [67.52.77.54]) by netgate.com (Postfix) with ESMTP id B86DE280019; Tue, 30 May 2006 15:57:14 -0700 (PDT) In-Reply-To: <20060530223511.GA83083@freebie.dcfinc.com> References: <447B6870.8020704@nortel.com> <20060530223511.GA83083@freebie.dcfinc.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <50372FCA-0668-476F-8FD5-0F5EAE167891@netgate.com> Content-Transfer-Encoding: 7bit From: Jim Thompson Date: Tue, 30 May 2006 12:57:12 -1000 To: "Chad R. Larson" X-Mailer: Apple Mail (2.750) Cc: small@freebsd.org Subject: Re: 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: Tue, 30 May 2006 22:57:27 -0000 On May 30, 2006, at 12:35 PM, Chad R. Larson wrote: > On Tue, May 30, 2006 at 06:30:45AM +0100, James Mansion wrote: >> The scenario would seem to be: >> - very small form factor and cost per unit >> - so no physical spinning disk >> - *and* you need a lot of updates >> >> Its the last of these that bears scrutiny. > > I've been using m0n0BSD on Soekris hardware. The "disk" is a CF > card, and booting consists of creating a RAM drive and then > populating it from the CF. The CF stays mounted R/O unless some > persistant information (like, configuration) needs to be saved, at > which time it is remounted R/W until the update is completed and > then put back to R/O. Systems with soldered on flash could hold the 'configuration' in a small number of flash sectors, with a checksum. If the checksum doesn't match, then a 'default' configuration could be used (stored in the RO part of the flash). m0n0 and pfsense largely point the way here, though PHP is a big footprint for a system with minimal flash. > This satisfies the "no moving parts" and small form factor issues. > > It seems to me that if the VM could/would be willing to do its > demand paging off the CF, so RAM would only have to hold dirty pages > that we'd hit the sweet spot for embedded systems of small to medium > production runs. Especially since CF is now available in gigabyte > sizes. Not all embedded projects use boards that can use CF.