From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22513 invoked by alias); 26 May 2006 13:02:07 -0000 Received: (qmail 22493 invoked by uid 22791); 26 May 2006 13:02:04 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_00,TW_DW,TW_WM X-Spam-Check-By: sourceware.org Received: from canuck.infradead.org (HELO canuck.infradead.org) (205.233.218.70) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 May 2006 13:01:38 +0000 Received: from pmac.infradead.org ([81.187.2.168]) by canuck.infradead.org with esmtpsa (Exim 4.62 #1 (Red Hat Linux)) id 1FjbwZ-0007ar-TW; Fri, 26 May 2006 09:01:35 -0400 Subject: Re: JFFS2 on eCos From: David Woodhouse To: Gary Thomas Cc: ecos-devel@sources.redhat.com In-Reply-To: <1148637331.20237.15.camel@hermes> References: <1148599617.14160.30.camel@shinybook.infradead.org> <1148637331.20237.15.camel@hermes> Content-Type: text/plain Date: Fri, 26 May 2006 13:02:00 -0000 Message-Id: <1148648488.28878.43.camel@pmac.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2.dwmw2.1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2006-05/txt/msg00028.txt.bz2 On Fri, 2006-05-26 at 03:55 -0600, Gary Thomas wrote: > Put my head on the block :-) Tell me what needs to be done and how > and I'll make sure it happens. OK, thanks.... I'll give you a quick overview of what we have, and what needs doing. When we first did the eCos port, I split Linux-specific stuff from 'core' JFFS2 code, putting them into separate files in the CVS tree. We added an 'ecos' subdirectory, containing jffs2.cdl and the eCos-specific files to match the Linux ones. I think you've seen all that anyway. What I need primarily is someone to take overall responsibility for keeping the eCos files up to date when we change stuff that affects them -- and to keep them up to date with eCos itself. Presumably also to merge JFFS2 code into the eCos tree. That task doesn't have to be all coding -- it can also include LARTing me (and other JFFS2 developers) if/when we break the eCos build without reason, without fixing up the eCos side ourselves, and/or without at least giving you a heads-up. (For example, if you refer to the changes I've made in the git tree in the last few days, I would expect a kicking for putting the new jffs2_prealloc_raw_node_refs() function into malloc.c, which is an OS-specific file, instead of putting it into a shared file. It's a function which should be the same in both cases. I'll fix that.) How you do this technically is ultimately up to you. What I'd probably suggest is that we should keep the eCos version on git.infradead.org, so it is immediately to hand and you can quite reasonably expect people to keep it working. With a little bit of git hacking, we should be able to set up a git tree which contains just the OS-independent files, and which inherits changes automatically from the main mtd-2.6.git tree. Then we can do a git tree for the eCos version which merges from that as and when appropriate. If that's how you want to do it, I'll go and set up the script to do that JFFS2-only tree, and set up the eCos repository based on that and the latest version of the eCos-specific files from CVS. Aside from setting that up, what needs doing right now is to make it build on eCos again, since I assume it doesn't. Take the JFFS2 files from the mtd-2.6.git tree, add the latest eCos files (which were last updated in July of last year), and make them work. You might benefit from doing that incrementally -- perhaps starting with the version in the 2.6.16 kernel, which is before all the changes I've just made, but _after_ the introduction of the 'erase block summary' code. Alternatively, you might prefer just to do it all in one fell swoop with the current code. -- dwmw2