Date: Tue, 30 May 2006 06:30:45 +0100 From: "James Mansion" <james@wgold.demon.co.uk> To: "Andrew Atrens" <atrens@nortel.com> Cc: Alexander Leidinger <Alexander@Leidinger.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, small@freebsd.org Subject: RE: FreeBSD's embedded agenda Message-ID: <HCEPKPMCAJLDGJIBCLGHAELDFGAA.james@wgold.demon.co.uk> In-Reply-To: <447B6870.8020704@nortel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?HCEPKPMCAJLDGJIBCLGHAELDFGAA.james>