On 01/26/2012 02:18 AM, Somebody in the thread at some point said: > I'm not sure about that: for Debian/Ubuntu there are established > methods for getting source and provenance info. It's a solved > problem, so we should just use the mature solution instead of > insisting on inventing our own.
The established way of handling getting source in real distros is issue a kernel source package matching the binary. For a complete solution - including any sauce added at packaging time - I don't think there's an alternative to the packager providing source. LTs are not naturally synchronized to what packagers are using and frankly at times when we're overloaded with keeping our head above water on tracking, or excitement with linux-linaro-tracking, dealing with these monthly releases is a headache. If packagers, who do have the exact source they are packaging, provide the sources (including sauce), there will be no possibility of loss of sync with what is provided no matter what the packaging side are doing. For provenance, it has been a real problem even before monthly release effort, people have often said they have something going wrong on ".1234" ie, using packaged build revision ordinal, or some tree I never heard of. I am then reduced to asking "uh... what tree is that? It's based on our stuff?" and often they don't know either. Locally I tag builds by passing in EXTRAVERSION to make, I tag it with "output directory name", which is "panda", then branch, eg, "3.3.0-panda_tracking-topic-audio-t31u+" which goes on to appear in boot log and become uname -r. In the past I added git HEAD hash too. However the space for that EXTRAVERSION info is limited in the kernel. Maybe what we should do here is append to the compressed kernel at build-time some coordinates for getting the matching sources, eg $ cat provenance # __WHERE_IS_THE_SOURCE__ git://git.linaro.org/landing-teams/working/ti/kernel.git tilt-3.2 8ae3d379998c7f48c73251d8f60b31b2b82a817d $ cat provenance >> uImage $ cat uImage | sed 1,'/# __WHERE_IS_THE_SOURCE/d' git://git.linaro.org/landing-teams/working/ti/kernel.git tilt-3.2 8ae3d379998c7f48c73251d8f60b31b2b82a817d Existing boot flow doesn't care about appended data, it doesn't get loaded because it's past the U-Boot header length field. But it will then be easy to find out where to get matching sources even for non-booting kernel binary with no other information where it came from. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
