On Wed, Jun 01, 2011 at 04:13:40PM -0400, James Westby wrote:
Luckily I missed that call, I have no confusion and this sounds perfectly sensible to me :-)
Though now I'm stuck with a confusing Subject line to compensate :-/
The config is available in /boot isn't it?
Good point.
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.
That's what I was thinking.
- 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.)
That's true, and I didn't finish my original sentence but I would have pointed out that more complete hardware packs would contain other vendor-supplied binaries. Having a version for them described would be great to have for debugging reasons, but I guess it's available in the packaging?
- 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 main motivation is around the kernel (answering the question "what kernel is being used for this hwpack") though I guess it applies to anything we have source for. Apart from the kernel and bootloader, are we supplying anything in the hwpack we have source for?