>These days, I believe the separate oprofile backend for ARM has gone
>away, and oprofile is implemented using the perf backend anyway.
I've been asked to look into this some more. I will post what I learn.
-dl
Hello,
We're elaborating our Linaro Gerrit (2.2.1) set up, and would like to
enforce separation between upstream and "our" branches, to disallow
stray commits to upstream branches and keep them pullable from AOSP.
So, we'd like to limit review requests, pushes, etc. to
"refs/heads/for/linaro*" and "refs/heads/linaro*".
Trying to enter exactly that into refs entries for All Project's ACL
lead to "Invalid Name" error. After looking at Gerrit's source, it
turns out that Gerrit expects *-using pattern to end with "/*". Well,
why? Yes, it's nice idea to use hierarchical-like branch names.
Sometimes. But there're also good reasons to restrict branch name to
generic "identifier". For example, to keep one-to-one mapping with
filenames (confined to some dirs), or database names (both useful for
CI for example). So, requiring slash present before "*" seems like
arbitrary restrictions.
Anyway, I wasn't too upset, knowing that arbitrary patterns can be
encoded using regexps, and that's where real surprises start. First of
all, looking at example regexps at
http://gerrit.googlecode.com/svn/documentation/2.2.1/access-control.html#_p…
there were suspiciously stray backslashes in pattern examples. Anyway,
I tried to input "^refs/heads/linaro.*", it was rejected with "Invalid
Name" error. Same for "^refs/heads/linaro.*". Then I just tried example
from the doc, both as is and with slashes stripped -
"\^refs/heads/[a-z]\{1,8\}" & "^refs/heads/[a-z]{1,8}". Same error.
Looking at the source, validation for regexp case is complicated (and
nothing points to backslashes being required): it seems to generate a
subject string which would match entered pattern, and test that simple
for being good refs syntax. Well, I thought, maybe UI validation
outslies itself, and commit changes directly to project.config of
refs/meta/config branch of All-Project. No avail. With config like:
[access "^refs/for/refs/linaro.*"]
push = group Registered Users
it's not possible to submit review against any branch at all.
Thinking here would be that may be regexp library is not available, or
regexp syntax is not enabled by some option, but just searching reviews
with queries like below works just ok:
"project:^platform/buil. status:open"
"project:^platform/buil.* status:open"
"project:^platform/buil.+ status:open"
So, I'm stumbled here - what could be wrong, and where to look next?
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi all,
I'm currently trying to get GCC to auto-detect what CPU to optimize for
by finding out what CPU it's actually running on (the user would only
have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo.
The problem is finding what magic numbers correspond to what CPU. I've
found the numbers for A8 and A9 empirically, but I'd like a longer list
than that!
Does anybody have a list of such numbers?
Or else, perhaps people could just post any number they happen to know?
I do have a few devices other than A8 and A9 lying around I can look at,
but the problem there is I don't actually know for certain what exact
CPU model those numbers map to, so confirmed numbers only please.
Thanks
Andrew
Is a method via the aux vectors to know at runtime if neon is or is
not present?
Thanks!
--
Regards,
Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
Enclosed please find the link to the Weekly Status report
for the kernel working group for the week ending 2011-08-26.
== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-08-29
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-09-01
== Summary, for details see the Status Report ==
* New kernel process overview doc is being drafted
https://docs.google.com/a/linaro.org/document/d/19bqP5akuMCEohb5Ko94emUWBVg…
* Submitted pl330 DMA driver device tree support patches for review.
* Samsung's uart irq handling patches that move irq handling from platform
code to driver is accepted in Greg's tty tree.
* Brought up i.mx6q SMP support
* Added the support of ARM Dormant/Shutdown mode on i.mx6q
* A v3.1-rc2 and device tree based kernel is running on i.mx6q
* i.MX code clean up and consolidation: patch-set has been merged to soc
tree.
* Pushed out v5 of the pinctrl/pinmux subsystem
* The bulk of gpio.h cleanup patches have been merged
* John Stultz Implemented the proposed config tooling for config
fragments, as will be presented at Plumbers conference
* Posted kprobes test code to the linux-arm-kernel list.
* Improved flash performance use case an simulation programs to provide
details of timings so that simulation accuracy can be mor easily judged.
* Submitted patches "Remove define CONSISTENT_DMA_SIZE" were pulled by
RMK for inclusion in Linux 3.2.
* Rebased and resubmitted a patch to get rid of a few StrongARM
cache-related build time constants (prerequisite to another patch series
removing most instances of <mach/memory.h>)
Best regards,
Mounir
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
Now that we have an Android build for every board and Gerrit and LAVA
I'd like to unify how we handle kernels for each so that we can work
more efficiently, start to unify the kernels and provide a means for
external Android users to start to improve these trees.
First, since we control the kernels that go into our Android builds
I'd like to follow AOSP convention and have:
kernel/common.git (john's tree)
kernel/imx53.git
kernel/omap.git
kernel/origen.git
kernel/snowball.git
(right now we have:
panda, beagle
<remote name="linaro-other" fetch="git://git.linaro.org/"/>
<project path="kernel" name="people/jstultz/android"
revision="linaro-android-3.0" remote="linaro-other"/>
panda-leb
<remote name="linaro-other" fetch="git://git.linaro.org/"/>
<project path="kernel" name="people/andygreen/kernel-tilt"
revision="tilt-jstultz-linaro-android-3.0" remote="linaro-other"/>
leb-snowball
<remote name="linaro-other" fetch="git://git.linaro.org/"/>
<project path="kernel" name="bsp/st-ericsson/linux-3.0-android-ux500"
revision="master" remote="linaro-other"/>
leb-origen
<remote name="linaro-other" fetch="git://git.linaro.org/"/>
<project path="kernel" name="people/angus/linux-linaro-3.0"
remote="linaro-other" revision="android"/>
leb-imx53
<remote fetch="git://git.linaro.org/" name="linaro-other"/>
<project name="people/bernhardrosenkranzer/android-kernel-iMX53"
path="kernel" remote="linaro-other"
revision="3d981d9418c53e3e1a079582088121c641588791"/>
)
I'd like these to be at git://android.git.linaro.org/. I'd like to not mirror.
Each tree would accept patches via Gerrit and be maintainable through
standard git by the tree maintainers. This should allow upgrades to
each, without needing to push all the upgrade patches through Gerrit.
Next, we'd like to point to a tip branch for each of these trees. This
branch would be were development would be happening. Tracking tip is
fundamental to continuous integration, if its broken then the primary
job of everyone should be getting it going again. I'd like to suggest
the branches be named the same and follow John's branch naming
convention:
linaro-android-3.0...etc
Lastly, I'd like to request (and we may be able to automate this once
all the kernels are co-located) that once a pinned-manifest.xml comes
out, referencing a specific sha1, I'd like to lay a tag on that sha so
it sticks around. Its better to tag after the fact because it saves
having to do another build/test/qa cycle and will ensure that our
pinned-manifest.xml continue to work.
I suspect a few growing pains, but I think this is going to be great.
Once the kernels are co-located we should be able to look at Gerrit
extensions that allow easier upstream patch submission and tracking.
We should also be able to more easily refactor things. Using the
Gerrit flow and extending it to support Android upstreaming is exactly
the thing Linaro was built for. Since Gerrit is such an integral part
of Android development, extensions to allow patch propagation would
allow a lot of the good work to flow back into the mainline kernel.
-Zach
