RE: [ECOS] Splitting the eCos repository

["Doyle, Patrick" <Patrick_Doyle at dtccom dot com>]

> -----Original Message-----
> From: Øyvind Harboe [mailto:oyvind.harboe@zylin.com] 
> Sent: Friday, August 11, 2006 5:24 AM
> To: ecos-discuss@ecos.sourceware.org
> Subject: [ECOS] Splitting the eCos repository
> 
> 
> How about splitting the eCos repository?
> 
> - It would help to market the support for multiple repositories. I've
> seen a lot of messy maintainence due to the lack of this knowledge.
> - It would reduce the size of the eCos repository that 90% use.
> 
> Something like:
> 
> - eCos core. Up to and including architecture HAL's
> - eCos devboard. Contains all the HAL's for development boards.
> - eCos highlevel/net. All high level(many files) stuff like net,
> microwindows, etc. goes
> - eCos legacy.
> 
> 1 eCos repository is too little, 10 is too many. :-)

I like it...

As I said, we already do much the same here.  One of the concerns I've had
about the OMAP ports is to wonder what happens when they get committed to
the repository.  (That has been dwarfed by my primary concern of when are we
ever going to find the time to formalize them).  Minor tweaks and additions,
not to mention total rewrites, need to go through an official maintainer
(which, with suitable negotiations, could be me) to commit them to the CVS
repository.  OTOH, I (here I use the royal "I", meaning Paul or Tom) could
simply maintain an OMAP repository, which would be available as a tarball,
periodically updated, through the eCos web site.  Then the 99.999999% of
folks using eCos on platforms other than the OMAP wouldn't have to deal with
the (albeit minor) bandwidth and disk space taken up by the OMAP port.
Lather, rinse, and repeat that for each processor and platform and you've
got a very sleak core OS plus additions for different applications.

I especially like the fact that eCos was designed from the ground up to be
easily portable to different platforms and processors.  I have yet to try
porting Linux to a new platform, and I know that a lot of progress has been
made in the area of modularizing it to make such ports easier, but I still
cringe at the thought.  Whereas, with eCos, I almost look forward to it :-)

Oops, that was way too much of a digression.

Anyway, I like your idea.  I think the split makes sense in theory... I'm
sure there would be a lot of discussion in the community regarding which
packages belong where, but eCos's inherent architecture would make such
changes easy to implement.

Great idea!
--wpd




--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss