Re: OMAP RedBoot port

Re: OMAP RedBoot port

[Jonathan Larmour]

Patrick Doyle wrote:
> I will be releasing Delphi's port of RedBoot for the OMAP shortly
> (hopefully, by the end of the week).  Full eCos support will follow someday.
> There are four possible means by which I can do so, listed in order of
> increasing preference:
> 
> 1) Dump the tarball on the patches list (or, or more accurately, a link to
> our FTP site containing the tarball) and request that one of the maintainers
> add it to the CVS repository.
> 
> 2) Place a tarball of the new files along with instructions on what to
> modify in ecos.db on Delphi's ftp server.

Don't know the difference between these two, but we should get it into CVS 
I'm sure. And all patches that go into CVS should be posted for discussion 
and archival on ecos-patches, although for something that big an FTP link 
may suffice.

> 3) Create an official "package" of the new files and place that on Delphi's
> ftp server.  I have a document somewhere around here that describes how to
> do that.  (Did that idea ever catch on -- do people distribute independent
> packages?)

They do _if_ it's not going in the master repo. Although out of interest 
in eCos 2.1 eventually, eCos is likely only to be distributed as EPK packages!

> 4) Request write access to the CVS repository so that I may commit the
> changes myself.
>
> Obviously, I am exploring option #4 right now, but I would welcome
> questions, comments, and/or snide remarks on the other three options.

This is an interesting point. So far we've restricted write access to 
(full) maintainers only. I would be interested in other maintainer's views 
on whether we should open this up more freely now, in the same way as GCC, 
GDB etc. where package maintainers are allowed to check stuff in for their 
own packages. This wouldn't be the same as a full maintainer - it's purely 
an efficiency improvement.

We would also, like GCC/GDB, have a top level MAINTAINERS file listing the 
responsibilities. Package maintainers would be able to commit directly to 
their "own" packages without waiting for approval. They can check in 
patches for other packages too if they like, but only with approval. *All* 
patches must go to ecos-patches in any case.

Comments?

 >  As
> per your suggestion, Jonathan, I have sent an email to msalter (I think I
> Cc'd you on that), so I could fold RedHat's port into mine (or vice versa)
> if that works out.  I would be glad to take up the responsibility of the
> official eCos OMAP maintainer.

Since no-one else here has a board, it seems reasonable :-).

> What do you think?  Are you two the right people to whom this question
> should be directed?

I think the maintainers list is the best place to discuss this, so I've 
CC'd that (which Gary is on).

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: OMAP RedBoot port

[Bart Veer]

>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:

    >> 3) Create an official "package" of the new files and place that
    >> on Delphi's ftp server. I have a document somewhere around here
    >> that describes how to do that. (Did that idea ever catch on --
    >> do people distribute independent packages?)

    Jifl> They do _if_ it's not going in the master repo. Although out
    Jifl> of interest in eCos 2.1 eventually, eCos is likely only to
    Jifl> be distributed as EPK packages!

    >> 4) Request write access to the CVS repository so that I may
    >> commit the changes myself.
    >> 
    >> Obviously, I am exploring option #4 right now, but I would
    >> welcome questions, comments, and/or snide remarks on the other
    >> three options.

    Jifl> This is an interesting point. So far we've restricted write
    Jifl> access to (full) maintainers only. I would be interested in
    Jifl> other maintainer's views on whether we should open this up
    Jifl> more freely now, in the same way as GCC, GDB etc. where
    Jifl> package maintainers are allowed to check stuff in for their
    Jifl> own packages. This wouldn't be the same as a full maintainer
    Jifl> - it's purely an efficiency improvement.

    Jifl> We would also, like GCC/GDB, have a top level MAINTAINERS
    Jifl> file listing the responsibilities. Package maintainers would
    Jifl> be able to commit directly to their "own" packages without
    Jifl> waiting for approval. They can check in patches for other
    Jifl> packages too if they like, but only with approval. *All*
    Jifl> patches must go to ecos-patches in any case.

    Jifl> Comments?

eCos is rather more package-oriented than gcc or gdb. We could end up
with a very large number of maintainers, most of them responsible for
only one or a small number of packages. Each maintainer is a potential
source of security problems, e.g. compromised ssh keys.

In an EPK-based system, it might make more sense to reduce the
importance of anoncvs. All the core packages would still go into
anoncvs, of course, but new ports and device drivers could instead
be provided only as EPK's. Releasing a new version would involve
generating a new EPK, putting it on sources.redhat.com in a write-only
incoming ftp directory, and then moving them to somewhere more public.
The latter could be done by a cron job or a script, possible with a
certain amount of validation by a human. A useful side effect would be
to keep down the size of the anoncvs tree itself: ports and device
drivers already account for a large proportion of the tree, and most
users are only interested in a small number of targets.

In that scenario, it might be better to stick with a small number of
people with write access.

Bart

Re: OMAP RedBoot port

[Jonathan Larmour]

Bart Veer wrote:
> 
>     Jifl> This is an interesting point. So far we've restricted write
>     Jifl> access to (full) maintainers only. I would be interested in
>     Jifl> other maintainer's views on whether we should open this up
>     Jifl> more freely now, in the same way as GCC, GDB etc. where
>     Jifl> package maintainers are allowed to check stuff in for their
>     Jifl> own packages. This wouldn't be the same as a full maintainer
>     Jifl> - it's purely an efficiency improvement.
> 
>     Jifl> We would also, like GCC/GDB, have a top level MAINTAINERS
>     Jifl> file listing the responsibilities. Package maintainers would
>     Jifl> be able to commit directly to their "own" packages without
>     Jifl> waiting for approval. They can check in patches for other
>     Jifl> packages too if they like, but only with approval. *All*
>     Jifl> patches must go to ecos-patches in any case.
> 
>     Jifl> Comments?
> 
> eCos is rather more package-oriented than gcc or gdb. We could end up
> with a very large number of maintainers, most of them responsible for
> only one or a small number of packages. Each maintainer is a potential
> source of security problems, e.g. compromised ssh keys.

That's a good point. The number of people with write access could 
proliferate out of control. I think it's probably only necessary when we 
can foresee a large amount of CVS access being required.

So unless anyone else has a view, then Patrick, please go with posting the 
patch for approval as before.

Ta,

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

RE: OMAP RedBoot port

[Patrick Doyle]

> That's a good point. The number of people with write access could
> proliferate out of control. I think it's probably only necessary when we
> can foresee a large amount of CVS access being required.
>
> So unless anyone else has a view, then Patrick, please go with
> posting the
> patch for approval as before.
>

Look for it real soon now...(hopefully this week, probably next week, at the
rate things are going here).

My one concern with this approach is that, for a little while, I expect the
OMAP port to be under fairly active development.  I am currently planning on
releasing what I have so far (which is basically enough to get RedBoot
working) ASAP, and then continue on the rest of the basic eCos port
(interrupts, etc...) as time permits, and then continue with device drivers
for the plethora of devices on the chip.  I am doing so under the "release
early, release often" approach to software development.  (Also, I am
sneakily hoping someone else who worked on eCos for the OMAP might
contribute to the parts I left out).

Would temporary or trial write access to the CVS repository be possible?  Do
you mind applying patches on a sporatic basis as I post them to
ecos-patches?

OTOH, my immediate end goal is to run Linux on the OMAP.  So it is likely
that I will be focusing much more on the Linux side of things than on the
eCos side of things in the very near future.  (Having said that, I'll
probably get a customer tommorow who wants eCos first, then Linux... I
should be so lucky! :-)

So, before your very eyes, I think I am talking myself out of the need for
immediate write access to the repository.  If I start posting so many
patches to the list that it becomes burdensome, to me and/or to you, then we
should talk some more about this.

--wpd

Re: OMAP RedBoot port

[Jonathan Larmour]

Patrick Doyle wrote:
>>That's a good point. The number of people with write access could
>>proliferate out of control. I think it's probably only necessary when we
>>can foresee a large amount of CVS access being required.
>>
>>So unless anyone else has a view, then Patrick, please go with
>>posting the
>>patch for approval as before.
>>
> 
> 
> Look for it real soon now...(hopefully this week, probably next week, at the
> rate things are going here).
> 
> My one concern with this approach is that, for a little while, I expect the
> OMAP port to be under fairly active development.  I am currently planning on
> releasing what I have so far (which is basically enough to get RedBoot
> working) ASAP, and then continue on the rest of the basic eCos port
> (interrupts, etc...) as time permits, and then continue with device drivers
> for the plethora of devices on the chip.  I am doing so under the "release
> early, release often" approach to software development.  (Also, I am
> sneakily hoping someone else who worked on eCos for the OMAP might
> contribute to the parts I left out).

Alas that was Jesper, who is now elsewhere.

> Would temporary or trial write access to the CVS repository be possible?  Do
> you mind applying patches on a sporatic basis as I post them to
> ecos-patches?

I'd prefer not to bother the sources.redhat.com maintainers and just deal 
with the patches.

> OTOH, my immediate end goal is to run Linux on the OMAP.  So it is likely
> that I will be focusing much more on the Linux side of things than on the
> eCos side of things in the very near future.  (Having said that, I'll
> probably get a customer tommorow who wants eCos first, then Linux... I
> should be so lucky! :-)
> 
> So, before your very eyes, I think I am talking myself out of the need for
> immediate write access to the repository.  If I start posting so many
> patches to the list that it becomes burdensome, to me and/or to you, then we
> should talk some more about this.

Sure. Although I'm sure you'll probably batch them up anyway. For a new 
package, don't forget to start a new ChangeLog! I'll also want some info 
for http://sources.redhat.com/ecos/hardware.html but I'll probably be able 
to get that myself once I know exactly what board you've got.

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine