[Ping] Re: [ARM] Initializing TTBR0 to inner/outer WB

[Corinna Vinschen]

On Apr 11 17:13, Jiong Wang wrote:
> On 31/03/16 16:34, Jiong Wang wrote:
> >On 26/03/16 11:47, Corinna Vinschen wrote:
> >>On Mar 24 14:32, Jiong Wang wrote:
> >>>Adopted suggestion given by Richard offline to avoid using jump.
> >>>
> >>>OK fo trunk?
> >>>
> >>>Thanks.
> >>>
> >>>2016-03-25  Jiong Wang<jiong.wang@arm.com>
> >>>
> >>>libgloss/
> >>>   * arm/cpu-init/rdimon-aem.S: Set TTBR0 to inner/outer
> >>>   cacheable WB, and no allocate on WB for arch with multiprocessor
> >>>   extension.
> >>Applied.
> >
> >Hi Corinna,
> >
> >  Thanks very much for reviewing and committing this.
> >
> >  One more thing is about the backporting.
> >
> >  For primarily internal uses we are building toolchains based on various
> >  released versions of newlib.  Currently we are interested in newlib
> >  releases dating back to 2_2_0.
> >
> >  This bug fix on trunk is the latest in a number of bugfixes where it
> >  would be useful (to at least some of us in the community) if there
> >  were release branches on to which we could back port bug fixes. We
> >  have no particular interest in point release from such a branches at
> >  this time.  So Would it be acceptable to create branches perhaps with
> >  names of the form newlib-2_x anchored at the relevant release tags for
> >  this purpose?
> >
> >  Thanks.
> 
> Ping ~
> 
> If creating public release branches is not acceptable, is it OK we create
> ARM release branches placed in our own name space and backport bug fixes
> to that?

The issue we have is that we don't have official releases.  They are
snapshots so back-porting fixes on top of them isn't really correct.

Creating and maintaining special branches like you suggest also requires
to support and maintain extended user permissions apart from the
standard user permissions maintained by overseers.  But if we go this
route we'll end up doing exactly that.  Neither Jeff nor I have time and
incentive to do that.

What about just cloning the repo (github, gitlab, ...) and creating
release branches in your own repo?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20160411/474758fe/attachment.sig>