Re: FreeBSD's embedded agenda

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Poul-Henning Kamp wrote:
> In message <HCEPKPMCAJLDGJIBCLGHKEFNFGAA.james_at_wgold.demon.co.uk>, "James Mansi
> on" writes:
> 
>>>"The adequate has always been the worst enemy of excellence"
>>>
>>>Remember, it's: "FreeBSD, the best damn UNIX around", not "FreeBSD:
>>>Yet Another Mediocre UNIX".
>>
>>Well, I would counter:
>>
>>'Good enough means exactly what it says, and doing more is foolish'
> 
> 
> I think you seriously lack historical perspective if that is your
> considered opinion.

I suppose it depends entirely on your objective. If your objective is
making money and you want to be first to the market with your toaster,
then you scale back features or quality or both in favour of schedule.

And some people would argue that over-engineering a toaster is a waste
of time and money because the breakfast user doesn't really care how a
toaster works, just that it works ..  and if it breaks, they'll just
go buy another one for 20 bucks.

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.

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.

Putting on my selfish hat I'd love to have a filesystem that could run
directly on raw flash, but I was under the impression that writing a
filesystem from scratch is a serious undertaking. And given the
volunteer nature of this project I thought that partitioning the
problem into two - by first creating a driver that manages raw flash and
presents it as a disk (similar to what a CF would do) .. could be done
before or in parallel with creating a new journalling filesystem.

Obviously the raw driver would provide some extensions / hooks / hints
that the jfs could take advantage of ..

A bit more work/thought then writing a flash-specific filesystem perhaps
but -

* partitioning the work would mean that with just the first part
  completed many folks could use it / test it .. and give people
  a kick start on the embedded side

* the low level driver could be shared with the other bsd's .. this
  could mean better (and quicker) support for more flash parts

Maybe I'm barking up the wrong tree here though .. could it be that the
work delta between writing the full filesystem vs the 'CF-like' driver +
filesystem is relatively small ?  I don't know, I'm just asking. :)

Andrew.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEdz/b8It2CaCdeMwRAukJAJ9O2LfV7CzcaXcVo8/qObwaSzSUBACfX3sF
8+O5nZPZBCw7ECuLd4I7ijM=
=Yysu
-----END PGP SIGNATURE-----