API to download from snapshots and releases is live
Hi,
There are many scripts in use that parse the web interface for
snapshots and releases.linaro.org. This is far from ideal because
changes to the web interface can result in the scripts breaking. To
alleviate this problem an API has been introduced. The API is very
simple, just two new URLs and a new header when downloading files.
server/api/ls/path to file returns a JSON document containing all the
data shown by a file listing on the web interface. It can target
either a directory of a file.
server/api/license/path to file returns a JSON document containing
the licence information for the file pointed to. Both the license text
and the digest used to accept the license are returned. Including the
digest means that the choice of digest used internally can change without
re-writing clients - to the client this is just a magic string and they
don't need to care how it is generated.
When downloading a file you simply include the header
LICENSE_ACCEPTED, its value being a space separated list of license
digests representing the licenses that you have accepted.
e.g.
(license text and digest removed for brevity)
http://snapshots.linaro.org/api/ls/quantal/hwpacks/snowball/latest
{
files: [
{
mtime: 15-Mar-2013 08:29,
name:
hwpack_linaro-snowball_20130315-269_armhf_supported.manifest.txt,
size: 762,
type: text,
url:
/quantal/hwpacks/snowball/latest/hwpack_linaro-snowball_20130315-269_armhf_supported.manifest.txt
},
{
mtime: 15-Mar-2013 08:31,
name:
hwpack_linaro-snowball_20130315-269_armhf_supported.tar.gz,
size: 18.1M,
type: other,
url:
/quantal/hwpacks/snowball/latest/hwpack_linaro-snowball_20130315-269_armhf_supported.tar.gz
}
]
}
http://snapshots.linaro.org/api/license/quantal/hwpacks/snowball/latest/hwpack_linaro-snowball_20130315-269_armhf_supported.tar.gz
{
licenses: [
{
text: license text...,
digest: license digest...
}
]
}
wget --header=LICENSE_ACCEPTED: license digest...
http://snapshots.linaro.org/quantal/hwpacks/snowball/latest/hwpack_linaro-snowball_20130315-269_armhf_supported.tar.gz
There is a example client script that illustrates how to use the API here:
http://bazaar.launchpad.net/~linaro-automation/linaro-license-protection/trunk/view/head:/scripts/download.py
Usage: download.py URL
If URL points to a directory all files are downloaded.
If URL points to a file, just that file is downloaded.
It prints the license(s) for each file and waits for the user to
accept each one. It also stores which licenses the user has accepted
so they don't need to be re-accepted if the text hasn't changed.
--
James Tunnicliffe
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: BLS 13.03 RC1 ready for testing
Hi Viresh, (1) Recently I have done a lot of testing for the new RCU functionality (new RCU FNOHZ implementation, updated RCU no-callback implementation) which is scheduled for 3.11/3.12 mainline. In my tests it helped to keep the A15's quiet and showed power savings for some workloads. During last Linaro Connect people started to ask me if we can bring these features in already earlier. Would it be possible for you to merge in 'idlenocb.2013.03.18b' (based on v3.9-rc2) (or newer) from 'git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git' into your big.LITTLE MP tree? I talked to Paul McKenney about this and he would like to have this additional test coverage. I have performed the following tests: System comes up and pm-qa (cpufreq, cpuidle, cpuhotplug) on nano and FTS (mpbasic, mpcore, mpextended, mploadbalance, mpregression, pmump) on Android FS look good. (2) On top of the merge, we must assure that the TC2 default config file gets changed: Change the config file: * Set CONFIG_RCU_FAST_NO_HZ=y * Set CONFIG_RCU_NOCB_CPU=y * Set CONFIG_RCU_NOCB_CPU_ALL=y diff -Naur config_orig .config --- config_orig2013-03-13 14:15:10.574248125 + +++ .config2013-03-13 14:15:34.334248346 + @@ -93,9 +93,12 @@ CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set -# CONFIG_RCU_FAST_NO_HZ is not set +CONFIG_RCU_FAST_NO_HZ=y # CONFIG_TREE_RCU_TRACE is not set -# CONFIG_RCU_NOCB_CPU is not set +CONFIG_RCU_NOCB_CPU=y +# CONFIG_RCU_NOCB_CPU_NONE is not set +# CONFIG_RCU_NOCB_CPU_ZERO is not set +CONFIG_RCU_NOCB_CPU_ALL=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 Cheers, -- Dietmar -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: BLS 13.03 RC1 ready for testing
On 26 March 2013 22:52, Dietmar Eggemann dietmar.eggem...@arm.com wrote: Would it be possible for you to merge in 'idlenocb.2013.03.18b' (based on v3.9-rc2) (or newer) from 'git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git' into your big.LITTLE MP tree? I talked to Paul McKenney about this and he would like to have this additional test coverage. 13.03 release is already over and this would be available after that. (2) On top of the merge, we must assure that the TC2 default config file gets changed: Change the config file: * Set CONFIG_RCU_FAST_NO_HZ=y * Set CONFIG_RCU_NOCB_CPU=y * Set CONFIG_RCU_NOCB_CPU_ALL=y @Mathieu/Nicolas: you see any issues with these? I know we have been working on some issues with/without them for some time. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: BLS 13.03 RC1 ready for testing
On 13-03-26 11:27 AM, Viresh Kumar wrote: On 26 March 2013 22:52, Dietmar Eggemann dietmar.eggem...@arm.com wrote: Would it be possible for you to merge in 'idlenocb.2013.03.18b' (based on v3.9-rc2) (or newer) from 'git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git' into your big.LITTLE MP tree? I talked to Paul McKenney about this and he would like to have this additional test coverage. 13.03 release is already over and this would be available after that. (2) On top of the merge, we must assure that the TC2 default config file gets changed: Change the config file: * Set CONFIG_RCU_FAST_NO_HZ=y * Set CONFIG_RCU_NOCB_CPU=y * Set CONFIG_RCU_NOCB_CPU_ALL=y @Mathieu/Nicolas: you see any issues with these? I know we have been working on some issues with/without them for some time. The CONFIG_RCU_FAST_NO_HZ option is known to increase the likely hood of hitting a tight race condition in the cpu hotplug and smpboot thread area. The condition doesn't disappear when the option is off but it decreases the failure rate. Mathieu. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: BLS 13.03 RC1 ready for testing
On 13-03-26 12:31 PM, Mathieu Poirier wrote: On 13-03-26 11:27 AM, Viresh Kumar wrote: On 26 March 2013 22:52, Dietmar Eggemann dietmar.eggem...@arm.com wrote: Would it be possible for you to merge in 'idlenocb.2013.03.18b' (based on v3.9-rc2) (or newer) from 'git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git' into your big.LITTLE MP tree? I talked to Paul McKenney about this and he would like to have this additional test coverage. 13.03 release is already over and this would be available after that. (2) On top of the merge, we must assure that the TC2 default config file gets changed: Change the config file: * Set CONFIG_RCU_FAST_NO_HZ=y * Set CONFIG_RCU_NOCB_CPU=y * Set CONFIG_RCU_NOCB_CPU_ALL=y @Mathieu/Nicolas: you see any issues with these? I know we have been working on some issues with/without them for some time. The CONFIG_RCU_FAST_NO_HZ option is known to increase the likely hood of hitting a tight race condition in the cpu hotplug and smpboot thread area. The condition doesn't disappear when the option is off but it decreases the failure rate. Mathieu. What we could do is take it in 'next' and see how it behaves. After all the worst that can happen is to still observe the issue... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Google Summer of Code - interested?
Am 21.03.2013 18:42, schrieb Steve McIntyre: On Thu, Mar 14, 2013 at 09:57:33PM +, Steve McIntyre wrote: Hi folks, As a follow-up to my work in LEG on assembly scanning and optimisation for AArch64, we're considering applying as a mentoring organisation for the Google Summer of Code [1] this year. There's quite a lot of code out there that may benefit from porting (whether for support of AArch64 or for better performance) and I think we could usefully get some students involved to help with this. I'm planning on doing the bureacracy for the SoC application in the next few days. So, the reason why I'm posting about that here: is anybody else interested in joining in? Are there any other projects in/around Linaro where: a) a student could do some useful work; b) we have somebody prepared to act as a mentor ? If so, please let me know. The more ideas we can suggest for summer projects like this, the more likely we are to be accepted as a mentoring organisation by Google. [1] http://www.google-melange.com/gsoc/homepage/google/gsoc2013 Ping? I've had some questions from a few people about this, but no suggested projects or proclamations of interest as yet. We've got until the end of next week to apply as a mentoring organisation, so please get back to me ASAP if you have an interest in the Summer of Code. another topic might be ports to support OpenGLes. Starting point would be an analysis of the current build failures on armhf, and select some high-profile packages for porting. Matthias (not mentoring) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/5] clk: allow reentrant calls into the clk framework
On Thu, 2013-02-28 at 12:49 +0800, Mike Turquette wrote: Reentrancy into the clock framework from the clk.h api is highly desirable. This feature is necessary for clocks that are prepared and unprepared via i2c_transfer (which includes many PMICs and discrete audio chips) and it is also necessary for performing dynamic voltage frequency scaling via clock rate-change notifiers. This patch implements reentrancy by adding a global atomic_t which tracks the context of the current caller. Context in this case is the return value from get_current(). The clk.h api implementations are modified to first see if the relevant global lock is already held and if so compare the global context (set by whoever is holding the lock) against their own context (via a call to get_current()). If the two match then this function is a nested call from the one already holding the lock and we procede. If the context does not match then procede to call mutex_lock and busy-wait for the existing task to complete. Thus this patch set does not increase concurrency for unrelated calls into the clock framework. Instead it simply allows reentrancy by the single task which is currently holding the global clock framework lock. Thanks to Rajagoapl Venkat for the original idea to use get_current() and to David Brown for the suggestion to replace my previous rwlock scheme with atomic operations during code review at ELC 2013. Signed-off-by: Mike Turquette mturque...@linaro.org Cc: Rajagopal Venkat rajagopal.ven...@linaro.org Cc: David Brown dav...@codeaurora.org --- Hi Mike, Will this single patch be accepted? I guess you might not merge the whole series but I think this one is useful, is it possible that you can send out this single patch (or just merge this one) as an improvement of CCF? Or you think otherwise? Thanks, Bill ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
