From owner-freebsd-small@FreeBSD.ORG Tue May 30 21:30:23 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 B43AA16A929 for ; Tue, 30 May 2006 21:30:23 +0000 (UTC) (envelope-from james@wgold.demon.co.uk) Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 334DB43D48 for ; Tue, 30 May 2006 21:30:18 +0000 (GMT) (envelope-from james@wgold.demon.co.uk) Received: from wgold.demon.co.uk ([158.152.96.124] helo=thor) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1FlBn6-000Jq6-6i; Tue, 30 May 2006 21:30:16 +0000 Received: from 127.0.0.1 by thor ([127.0.0.1] running VPOP3) with SMTP; Tue, 30 May 2006 06:30:47 +0100 From: "James Mansion" To: "Andrew Atrens" Date: Tue, 30 May 2006 06:30:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <447B6870.8020704@nortel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Server: VPOP3 V1.5.0k - Registered Cc: Alexander Leidinger , Poul-Henning Kamp , 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 21:30:34 -0000 >Consider that we're building something that's going to be used in >variety of applications with a variety of different 'good enough' >definitions. Well, if you really want to be all things to all men. I guess I'm coming from a point of view that this is a dumb thing to do. Do you want to be jack of all trades, or master of one (or at least some defined set)? If you want to be master of lots of trades, then you'd better not be in a hurry - and have lots of resource too. >Firstly, flash is not ram and flash is not a disk. I'm not trying to >be facetious, but you don't seem to have considered that the write-erase >paradigm is completely different for flash chips, versus disks or >ram. Yes I have. I've suggested that you reduce the number of writes, then you can consider what the lifetime is assuming that all writes hit the same sector. You only *need* wear levelling if this impacts the design life of a unit, right? >development system. But if you're stamping out a lot of them it is >really going to eat into profit margins. Yes, and then you don't necessarily need a general purpose system. Because you have a lot of economy of scale. >For the rest of us, who aren't rolling our own hardware, we gotta use >what's available. Jim Thompson for instance uses WRAP boards for some In effect I am suggesting that BSD target *this* sort of embedded use, and be very good at it, rather than try to run a phone or a gameboy. >Form factor, and cost if you're building your own h/w. If not then you >need to use what general use platforms are available, and currently >the CF supporting ones are a bit pricey. Huh? CF (or the other newer smalled form factors like SD) is pretty cheap for low volume stuff, surely? Economy of scale for cameras, phones and PDAs has driven that. >So then we agree - write a driver that makes raw flash look like a CF, >and does wear-levelling, gc, etc, under the hood. Then put whatever Well, no, because I question whether wear-levelling is *necessary* for many potential applications, because that in itself implies a lot of writes must be supported. And if a lot of writes must be supported, why not use a microdrive? 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'm suggesting that this is a small slice of the embedded pie in terms of people using FreeBSD: I'm suggesting that if you can limit and control the number of ohysical (not even logical) writes then the wear on a single sector of flash can be reduced to the point that wear levelling is not necessary, and is just a 'nice to have'. I think in terms of the overall embedded pie, then sure the form factor is an issue, but you have to question how many writes must be supported, relative to the cycles available in modern flash - which has itself improved. James