From owner-freebsd-current@FreeBSD.ORG Fri May 26 17:51:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F314116A5B3; Fri, 26 May 2006 17:50:59 +0000 (UTC) (envelope-from ATRENS@nortel.com) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB39C43D5C; Fri, 26 May 2006 17:50:58 +0000 (GMT) (envelope-from ATRENS@nortel.com) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4QHoU414572; Fri, 26 May 2006 13:50:30 -0400 (EDT) Received: from [10.0.10.2] ([47.128.166.148] RDNS failed) by zcarhxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 13:50:28 -0400 Message-ID: <44773FDB.1090901@nortel.com> Date: Fri, 26 May 2006 13:50:19 -0400 From: "Andrew Atrens" User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051129) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <9822.1148656872@critter.freebsd.dk> In-Reply-To: <9822.1148656872@critter.freebsd.dk> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2006 17:50:28.0302 (UTC) FILETIME=[DFDC1EE0:01C680EC] X-Mailman-Approved-At: Fri, 26 May 2006 18:07:02 +0000 Cc: current@freebsd.org, Alexander Leidinger , James Mansion , small@freebsd.org, Olivier Gautherot Subject: Re: FreeBSD's embedded agenda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 17:51:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Poul-Henning Kamp wrote: > In message , "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-----