This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Re: [Ping] Re: [ARM] Initializing TTBR0 to inner/outer WB
- From: Jiong Wang <jiong dot wang at foss dot arm dot com>
- To: vinschen at redhat dot com
- Cc: newlib at sourceware dot org, Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Date: Thu, 14 Apr 2016 14:40:42 +0100
- Subject: Re: Re: [Ping] Re: [ARM] Initializing TTBR0 to inner/outer WB
- Authentication-results: sourceware.org; auth=none
- References: <56F0095C dot 4040408 at foss dot arm dot com> <56F3FA64 dot 5050307 at foss dot arm dot com> <20160326114702 dot GC8327 at calimero dot vinschen dot de> <56FD439C dot 3070306 at foss dot arm dot com> <570BCD46 dot 10604 at foss dot arm dot com> <20160411164048 dot GA26994 at calimero dot vinschen dot de>
On 11/04/16 17:40, Corinna Vinschen wrote:
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.
I don't believe overseers manage any additional permissions more than
the standard write privileges for the gcc tree (even though it uses svn)
or the other trees where folks have private branches. The protocol is
pretty simple in the GCC world for it since that is the one I'm most
familiar with - anyone with write privileges can create a branch with
some simple documented rules about what gets committed there and who
commits to those branches. The only rules that apply in the gcc list are
that patches be posted to the main patches list. Wouldn't that protocol
suffice for newlib ?
What about just cloning the repo (github, gitlab, ...) and creating
release branches in your own repo?
I would personally prefer to create a branch since it keeps all the
information in one repository - a surfeit of github / gitlab clones for
anyone who wants to create a branch only adds to confusion IMHO.
My 2 cents.
Regards,
Jiong
Corinna