Re: Getting Atmel AT91SAM9 into eCos

[Jonathan Larmour <jifl at jifvik dot org>]

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