From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20773 invoked by alias); 8 Mar 2010 13:54:25 -0000 Received: (qmail 20765 invoked by uid 22791); 8 Mar 2010 13:54:24 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Mar 2010 13:54:19 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id o28DsEt14759; Mon, 8 Mar 2010 13:54:14 GMT Received: from [172.31.1.2] (unknown [172.31.1.2]) by jifvik.dyndns.org (Postfix) with ESMTP id A008B3FE1; Mon, 8 Mar 2010 13:54:12 +0000 (GMT) Message-ID: <4B950183.7070004@jifvik.org> Date: Mon, 08 Mar 2010 13:54:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc3.4.legacy (X11/20060515) MIME-Version: 1.0 To: John Dallaway Cc: eCos Maintainers , Evgeniy Dushistov , Daniel Helgason Subject: Re: Getting Atmel AT91SAM9 into eCos References: <1266877649.3024.105.camel@localhost.localdomain> <4B839F37.50904@dallaway.org.uk> <4B94F776.1040707@dallaway.org.uk> In-Reply-To: <4B94F776.1040707@dallaway.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2010-03/txt/msg00009.txt.bz2 John Dallaway wrote: > eCos maintainers > > John Dallaway wrote: > > >>Daniel Helgason wrote: >> >> >>>I have seen many messages on the eCos mailing lists about getting >>>AT91SAM9 support into eCos. I'm writing directly to you in hopes of >>>getting some movement on this. I know this is off the mailing list but I >>>wanted to get initial input directly from people whose opinions I have >>>come to respect before I add yet another message to the mailing list >>>about this subject. >> >>[ snip ] >> >> >>>If there was ever a time to consider pushing the AT91SAM9 devices into >>>eCos, this could be it! I am asking you for your thoughts on how to >>>proceed from here. Thanks! >> >>I am not an expert on ARM7/ARM9 differences but there are several eCos >>maintainers who have experience with multiple ARM variants and are well >>positioned to review the AT91SAM9 patch. I do not think motivation >>should be an issue here. We all wish to see eCos move forward and >>AT91SAM9 support is clearly very good for the project. >> >>My main concern is that we don't break eCos support for older ARM >>platforms in the process of improving the hardware abstraction for >>future platform ports. >> >>Is there an eCos maintainer with the necessary ARM expertise who can >>volunteer for the review of this contribution? > > > There has been no response to this. > > The review of Evgeniy's patch is particularly important at present to > avoid merging issues for various new and planned platform ports on > ARM7/9. It is also important that the variant abstraction re-work is > reviewed by someone with real expertise in the area. > > What do you suggest? Should we ask for a volunteer from the wider eCos > community to review the patch in this instance? In truth, the main reason I (and probably others) have been studiously ignoring this is because the patch is far-reaching. That doesn't make it bad, but there's a lot of risk (and effort) here, with potential knock-on for ports we can't retest easily, and effects for any eCos user's own ports we don't have in our repo. It would also be hard to apply such a patch while using CVS, due to its problems with moving things around. I will kick off a discussion about VCS's because w.r.t this patch or otherwise, it needs to be resolved. To do that, I need to go through the past discussion in the community and summarise what people have already said, then reopen discussion in the community. I'll try and do something this week. Although I'll be away next week. It doesn't feel right saying that we can't do something with the patch till we've switched VCS, but the practicalities do mean that there may be reasons to wait. It's likely this work would need to be committed initially on a branch. But again a reason for a new VCS is that merging from branch to trunk is much much much saner than with CVS, especially with moved files, renames, etc. (assuming the branch was made from the new VCS). Jifl -- ------["The best things in life aren't things."]------ Opinions==mine