Date: Tue, 30 May 2006 15:35:11 -0700 From: "Chad R. Larson" <chad@DCFinc.com> To: James Mansion <james@wgold.demon.co.uk> Cc: Alexander Leidinger <Alexander@Leidinger.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Andrew Atrens <atrens@nortel.com>, small@freebsd.org Subject: Re: FreeBSD's embedded agenda Message-ID: <20060530223511.GA83083@freebie.dcfinc.com> In-Reply-To: <HCEPKPMCAJLDGJIBCLGHAELDFGAA.james@wgold.demon.co.uk> References: <447B6870.8020704@nortel.com> <HCEPKPMCAJLDGJIBCLGHAELDFGAA.james@wgold.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. -crl -- Chad R. Larson (CRL15) 602-264-5009 chad@DCFinc.com Else: chad@larsons.org http://public.xdi.org/=Chad.R.Larson DCF, Inc., 1701 East Colter Street, Phoenix, Arizona 85016-3381
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060530223511.GA83083>