public inbox for
 help / color / mirror / Atom feed
From: Jonathan Larmour <>
To: John Dallaway <>
Cc: eCos Maintainers <>,
	   Evgeniy Dushistov <>,
	Daniel Helgason <>
Subject: Re: Getting Atmel AT91SAM9 into eCos
Date: Mon, 08 Mar 2010 13:54:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 

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).

------["The best things in life aren't things."]------      Opinions==mine

  reply	other threads:[~2010-03-08 13:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1266877649.3024.105.camel@localhost.localdomain>
2010-02-23  9:26 ` John Dallaway
2010-02-23  9:58   ` Evgeniy Dushistov
2010-02-23 16:53     ` Gary Thomas
2010-02-23 17:50       ` Evgeniy Dushistov
2010-03-08 13:11   ` John Dallaway
2010-03-08 13:54     ` Jonathan Larmour [this message]
2010-03-08 15:59       ` John Dallaway
2010-03-09  2:00         ` Sergei Gavrikov
2010-03-09 16:30           ` Jonathan Larmour
2010-03-09 16:25         ` Jonathan Larmour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).