From owner-freebsd-current@FreeBSD.ORG Tue May 30 19:20:09 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 31E6616AE81 for ; Tue, 30 May 2006 19:20:09 +0000 (UTC) (envelope-from mf.danger@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BD3B43D5D for ; Tue, 30 May 2006 19:20:03 +0000 (GMT) (envelope-from mf.danger@gmail.com) Received: by nf-out-0910.google.com with SMTP id l37so5495nfc for ; Tue, 30 May 2006 12:20:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bdEt5vmwlhNecOyL+jHJ/0hD9f2xGNA50aLAWha1IfFWvNXuOCdWS9jhhgbO9z2BV76N7VtLPH/pS37pFpsEYAtiXgxBgjudlCS2oc+YlxOCHeggL/bmF3YshUtGRVTDAIME+vQLr8pCHWIj7KxJSJLSPX2tb5jXcDPCyO/zVCU= Received: by 10.49.9.19 with SMTP id m19mr39615nfi; Tue, 30 May 2006 12:12:44 -0700 (PDT) Received: by 10.49.49.17 with HTTP; Tue, 30 May 2006 12:12:43 -0700 (PDT) Message-ID: <9f7850090605301212n57cd4d70k735881f121b5fe6d@mail.gmail.com> Date: Tue, 30 May 2006 12:12:43 -0700 From: "marty fouts" To: "John Birrell" In-Reply-To: <20060530051455.GA60261@what-creek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <447B6870.8020704@nortel.com> <20060530040220.GA59831@what-creek.com> <9f7850090605292201x570d93b4v8a7dd3ea0c70f841@mail.gmail.com> <20060530051455.GA60261@what-creek.com> Cc: Alexander Leidinger , Poul-Henning Kamp , Andrew Atrens , current@freebsd.org, small@freebsd.org 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: Tue, 30 May 2006 19:20:20 -0000 On 5/29/06, John Birrell wrote: > On Mon, May 29, 2006 at 10:01:37PM -0700, marty fouts wrote: > > Unfortunately, in my world, the smallest embedded system isn't of > > interest. We need something a bit larger. That threaded program needs > > a data store for persistant data. > > Yes, you write persistent data to the NAND disk. As I said, you remount > the file system as write enabled when you need to save data then leave > it read-only for the rest of the time. This doesn't take very long to do. > It's not like you have gigabytes of data buffered because you mount > the file system write enabled synchronously. A smartphone is constantly writing data to persistant storage. It needs a real file system that's r/w all the time. > The example that I gave uses NAND flash to boot the OS and save > persistent configuration data. The CF was only used because the MPEG > file for a race video was 1GB. If I wasn't writing such a large amount > of data, the CF would not have been required. At the time it was the > easiest way to get a large amount of storage in a small system which > had to stand the rigor race motorcycle vibrations. The next generation of smartphones are likely to have GBs of NAND storage. Some of them are going to include ipod-like NAND based media players and the ability to capture mpeg. They're still not going to have room for a CF card. > If you study the NAND implementations on embedded hardware, > you will see that making a general operating system support them all with > drivers is hard to do because of the different ways that the NAND chips > are mapped in I/O. It's not like they are on a general bus that makes > access to them the same. This is a general observation about embedded devices. GPIO is your friend. If you look at, for instance, the evolution of OMAP support in Linux, you'll see a succession of attempts to abstract a GPIO support service that provides an abstraction like the bus abstraction to deal with this. I think your comments highlight the difference between doing one-off embedded devices, like your motorcycle camera, where quick hacks and custom drivers are utterly appropriate, from doing long lived families of embedded devices, where you have to routinely deal with several generations of hardware. If FBSD wishes to be the best-of-the-best and play in the embedded space, then it has to accomodate the later as well as the former.