Date: Mon, 29 May 2006 17:32:32 -0400 From: "Andrew Atrens" <atrens@nortel.com> To: James Mansion <james@wgold.demon.co.uk> Cc: current@freebsd.org, Alexander Leidinger <Alexander@Leidinger.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, small@freebsd.org, Olivier Gautherot <olivier@gautherot.net> Subject: Re: FreeBSD's embedded agenda Message-ID: <447B6870.8020704@nortel.com> In-Reply-To: <HCEPKPMCAJLDGJIBCLGHKEHMFGAA.james@wgold.demon.co.uk> References: <HCEPKPMCAJLDGJIBCLGHKEHMFGAA.james@wgold.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Mansion wrote: >>On the other hand, if you're building an embedded system for a lunar >>lander for Apollo 13, or a real time control system, then I would argue >>that you should squeeze in as many engineering cycles as you can, >>because a dependable system is only as robust as its weakest link. > > > I disagree. What you are building does not change the truism. All that > happens is that 'good enough' has a more stringent definition - that's > the whole point. I've always been a strong believer that in software, as in geology, the macro structure reflects the micro structure. Consider that we're building something that's going to be used in variety of applications with a variety of different 'good enough' definitions. Consider VxWorks, a popular embedded OS that's used in a variety of NASA projects, but I'm sure is also used in some toasters, too. So your 'good enough' quality idea doesn't apply well to something like BSD (or VxWorks) that are really just 'general purpose' building blocks because we don't know the final application and hence that product's 'good enough' definition. >>Having said that, I don't think James initially knew that a CF does >>wear-levelling - so perhaps he doesn't have that much direct experience >>with these devices. > > > I thought I made the point that I believe many do. But once again the > issue here is not whether the do or not, its whether wear-levelling > is a requirement. A modern flash device will handle many updates > per sector, and a device that runs from flash is presumably intended > not to be update-heavy. So long as you don't perform unnecessary > housekeeping IO's such as flushing access times frequently, then > you'll generally be fine. Do the maths. Systems tend to update > /tmp and /var quite a lot, even then if you can avoid flushing the > sectors with directories and delaying them, then you can get > to a the point where the design life is not limited by the flash > device. I really have to disagree with you on that one. I don't know where to start though. 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. One of the value-added's that CF gives you is that it makes flash 'look' like a disk, so that you can access it using a disk-access paradigm. To keep it simple, you can't just 'put' a r/w filesystem directly on a memory mapped Flash chip - it just won't work. I'm not into the theoretical here. I've worked in telecom, in the embedded space, for almost 12 years. Almost all of that has been on moto platforms, but lately as a hobby (for about a year and a half or so) have been playing with pc-engines WRAP boards. Thing is, and I believe Marty said the same for phones, the form factor for CF is kinda big, and cost is also a factor. So people that are rolling their own hardware have no incentive to use it. Great for a development system. But if you're stamping out a lot of them it is really going to eat into profit margins. 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 of his routers. I'm sure he'd dearly love to find a cheaper platform to build BSD-based CPE gear on. Heck I would, too. Some of the little MIPS (and ARM) based platforms appear to excellent. And none that I know of use CF - for two reasons - form factor and unit cost. >>Putting on my selfish hat I'd love to have a filesystem that could run >>directly on raw flash. > > > Why? Lets remember we're talking about an embedded system that can be > sensibly implemented with a general purpose OS. I'd put it to you that > normally where this is very desirable, its because the run rate is > quite low so the project overall is very sensitive to ease and cost of > development. But if the run rate is low, then you also need to consider > what hardware will be available in volume at go-live, and CF-to-IDE > is very cheap now in conjunction with system-on-a-chip designs for > set top boxes. For big bulk, we have PIC, Atmel, Rabbit, and assorted > 80186 designs (including one very cute thing I saw built into an > ethernet PHY) 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. > If you really must wear level, then why not access through a layer that > divides the whole CF into 'n' partitions, uses 'n-1' of them, re- > presents the 'n-1' through a RAID0-like mapping, and allows the logical > sector 0 in each partition to be changed (with wrap-around). > Then you can use a real filesystem on top of the block-mapping layer, > and the mapper can move the hotspot around the disk much as a RAID > array can rebuild under a real system. 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 f/s you want on it. it's a start at least. Then build your kick-ass NAND-aware (or NOR aware or both) fs on top of that that makes use of some extensions that the driver provides. Okay, that's quite the arm wave ... I must admit that I don't know so much about the existing fs<->disk interface... Andrew. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEe2hw8It2CaCdeMwRAqGcAJ4qEuTpVQGFMZKwID6UdXnpyN5f4gCgnvhG ki/EOHOmzFisoEjyY5wxUjw= =nZ5y -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?447B6870.8020704>