From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18910 invoked by alias); 9 Mar 2010 16:25:56 -0000 Received: (qmail 18828 invoked by uid 22791); 9 Mar 2010 16:25:53 -0000 X-SWARE-Spam-Status: No, hits=-2.3 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; Tue, 09 Mar 2010 16:25:49 +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 o29GPXt03989; Tue, 9 Mar 2010 16:25:33 GMT Received: from [192.168.7.9] (unknown [78.32.57.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id BFFE23FE1; Tue, 9 Mar 2010 16:25:32 +0000 (GMT) Message-ID: <4B96767B.9060108@jifvik.org> Date: Tue, 09 Mar 2010 16:25:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3 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> <4B950183.7070004@jifvik.org> <4B951EE0.6020103@dallaway.org.uk> In-Reply-To: <4B951EE0.6020103@dallaway.org.uk> Content-Type: text/plain; charset=ISO-8859-1 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/msg00012.txt.bz2 On 08/03/10 15:59, John Dallaway wrote: > Jonathan Larmour wrote: >> >> 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. > > I agree that the VCS debate needs to happen, but it seems dangerous to > link patch review with VCS changes in the sense that it introduces > further (unquantified) delay to the review of patches which have already > been pending for many months. I know it's not ideal, hence my comment about it not feeling right, but this patch in particular may justify it. > I am happy to volunteer for the hard graft of working with CVS if it > will help to get things moving on the ARM7/ARM9 front. It's not to do with hard graft using CVS. It's to do with proper configuration management, and tracking changes, and sensible merges. This patch moves a lot of stuff around between files. The right process for getting this support in (in a new VCS) is to create a branch, apply the patch, then make further changes and test in the branch, then merge to trunk. Of course once in the branch, anyone can start using it if they really want to. And as Sergei says I think the time is right to bring the VCS discussion to a close without it needing to drag out too long. >> 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). > > Having just had a more detailed look, it appears that the new ARM7 > package is only used by the ARM7 AT91 platforms as the patch stands > today. Yes but there are quite a few of those and they are popular. All sorts of people out there will have made their own ports. With things moving around, those ports break. It's not just a case of keeping the ports checked in to CVS working. > It is less invasive than I had imagined. The other ARM7 platforms > are untouched. So I think we could phase in use of the new ARM7 package > for new ports only. The changes to the ARM9 variant package are more of > an all-or-nothing proposition but we have several ports to ARM9 > platforms in progress within the eCos community so the changes will > certainly get tested. However, some of the ARM9 platforms supported > within the eCos repository are obsolete and are likely to never be > tested again so if we break such platform support it will probably stay > broken forever. We have to consider people's ports out there. People don't ship product based on an eval board - they have their own ports for their own hardware. Breakage should not be done lightly; it may well be necessary, but in that case we really have to be sure the abstractions are right to prevent having to break it again. (And having a VCS which can manage change sets will also make it a lot clearer to see what changes are required specifically to replicate the changes needed). > Jifl, should we think in terms of a ARM9 v2 variant package (like flash > v2) to mitigate the risk? Indeed I am advocating something like "flash v2" (which FAOD was always an informal name), which means development takes place on a branch and gets merged to trunk when we're happy with it, replacing what's there. FAOD it would be bad to have a new ARM9v2 package in the trunk. For the same reasons of avoiding unnecessary breakage of ports above, we'd have to keep it round forever. > If we can manage the risk and manage the CVS effort, the remaining major > obstacle to progress would be the verification that the abstractions are > correct. Perhaps an hour of effort for someone with the appropriate > experience? No, much more. From my own quick view of the sources, the idea looks roughly right, but the detail needs refinement. Jifl