On Wed, 1 Jun 2011 15:41:05 -0300, Christian Robottom Reis kiko@linaro.org wrote:
This week I initiated a confused conversation during the techleads
call about having a way to describe what the hardware pack was built from. We had a couple of false starts but I think we agreeing that there needs to be some form of manifest that describes what the hardware pack contains.
Luckily I missed that call, I have no confusion and this sounds perfectly sensible to me :-)
- My #1 use case is, once I've installed a hardware pack, running into a problem and then being able to verify whether it contains a certain patch or was built with a certain config option. I'd like to know that because it's the first thing the KWG and LT people ask me when I go to report the bug.
The config is available in /boot isn't it? As for whether a patch is in, if we can't easily go from package version to git id and work from there, then we should definitely add that regardless of anything else, as being able to do that quickly is regularly useful.
- I think there's also a use case of wanting to know how to get that hwpack rebuilt with slightly updated kernel code or configs. If it's much easier to just document how to build and replace a kernel for a running image, that may cater for most of that use case, the exception being weird bugs caused by our build process and/or toolchain.
I've long wondered if a repack-hwpack command would be useful.
We're also just starting some work on adding a way to add in a custom kernel at linaro-media-create time to support validation work, and we think it will be useful elsewhere. We're not entirely sure that we can pull it off in a seamless manner yet, we'll be experimenting this week to be sure.
- I wonder if there's a use case for understanding and/or replacing the other contents of the hardware pack. I normally think of the hardware pack as "a built kernel and not much else" XXX.
This is becoming less true over time it seems, with accelerated components making there way in to the hwpacks (SGX for OMAP.)
- What kernel tree it was built from (A URL to the git tree) - What revision (A revision ID) - What patches were applied on top of it (A URL to the patchset, maybe?) - What kernel config was used to build it (A separate file in the hwpack directory?)
How does that sound? Too simplistic?
This just seems to deal with the kernel?
My gut feeling is that all of this should be fairly straightforward, but the tough part will be co-ordinating across all of the different pieces to get it in one final report.
For instance, at hwpack creation time it's too late to know most of the things above, unless they are recorded in the kernel package. If they are then they can fairly easily be extracted and recorded.
Thanks,
James