Re: FreeBSD's embedded agenda

-----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-----