Date: Fri, 26 May 2006 13:50:19 -0400 From: "Andrew Atrens" <atrens@nortel.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: current@freebsd.org, Alexander Leidinger <Alexander@Leidinger.net>, small@freebsd.org Subject: Re: FreeBSD's embedded agenda Message-ID: <44773FDB.1090901@nortel.com> In-Reply-To: <9822.1148656872@critter.freebsd.dk> References: <9822.1148656872@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Poul-Henning Kamp wrote: > In message <HCEPKPMCAJLDGJIBCLGHKEFNFGAA.james@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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44773FDB.1090901>