From owner-freebsd-mips@FreeBSD.ORG Wed May 23 20:24:28 2007 Return-Path: X-Original-To: freebsd-mips@freebsd.org Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69CFC16A41F for ; Wed, 23 May 2007 20:24:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 29E0113C45B for ; Wed, 23 May 2007 20:24:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l4NKNWxn077892; Wed, 23 May 2007 14:23:33 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 23 May 2007 14:23:46 -0600 (MDT) Message-Id: <20070523.142346.-749246620.imp@bsdimp.com> To: bms@incunabulum.net From: "M. Warner Losh" In-Reply-To: <46549AE9.9040505@incunabulum.net> References: <46549AE9.9040505@incunabulum.net> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 23 May 2007 14:23:33 -0600 (MDT) Cc: freebsd-mips@freebsd.org Subject: Re: Anyone porting YAFFS2? X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2007 20:24:28 -0000 In message: <46549AE9.9040505@incunabulum.net> "Bruce M. Simpson" writes: : Has anyone out there considered porting YAFFS2 to FreeBSD? Looking at : the design notes it sounds fairly portable, more so than JFFS2: : http://www.aleph1.co.uk/taxonomy/term/31/ : : This could be a good test case for flash support as it seems that a : NEWBUS interface could be implemented for flash controllers, which : YAFFS2 could then use. I'm not sure a newbus interface is the right one to use, since most storage systems are built on the bio interface. We'd have to flush out the bio interface to cope. However, I think most of the things that are necessary already exist in the interface... : I'm not sure how GEOM would fit into this picture. The file system glue : strikes me as a minimal amount of work compared to the rest involved in : supporting this. There's already a geom_nand floating around in the while. It does the wear averaging, but is somewhat tied to some specific hardware and isn't done generically, and I'm not sure if I can give it out... : Whilst the code is available under GPL, the author(s) state that they : are 'open to arrangements'; I'm not sure what this implies, the : licensing information on their site suggests this is about negotiating : commercial licenses with them. It would seem acceptable to me that such : code could potentially be imported under src/sys/contrib, however, this : leaves the question of what we do about firmware images which : incorporate such a YAFFS2 build. GPL'd code is fine, so long as it is in src/sys/gnu. Warner