W dniu 01.06.2011 20:41, Christian Robottom Reis pisze:
Hello there,
This week I initiated a confused conversation during the techleadscall 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.
I seem to be hung up on having a way of saying "this hardware pack's kernel was built from this git tree with this config", so I wanted to explore the use cases a bit more:
My use case is similar:
I'm an LAVA probe and I want to determine the very same information so that reporting framework can cross-reference if with the test results.
In LAVA we have introduced a concept of SoftwareSource - source information about binary packages on the system. Each source denotes a code branch (either bzr, git or svn) and revision (or tag). This allows you to pinpoint GCC revision, kernel tree and other important pieces of information. You can later use this to draw some interesting conclusions (especially for system-level performance, kernel quality and so on).
It would be nice to standardize this information and actually store it inside the hardware pack.
One of the things it does not capture currently is kernel configuration. Assuming you can cat /proc/config it would be easy to capture that as well but I would like to know what others think.
Zach suggested SPDX (as in spdx.org) as a solution to this problem; I'm not sure I understand enough about it (Loïc's provided a sample file at http://spdx.org/wiki/sample-partial-spdx-file-geronimo) but here's my strawman proposal of what data we should give people quick access to:
While using SPDX might be interesting I would encourage us to look back at LAVA so that either we also use SPDX or if it's not feasible we all use some other sensible tool.
In LAVA terms:
- What kernel tree it was built from (A URL to the git tree)
SoftwareSource.branch_vcs + SoftwareSource.branch_url
- What revision (A revision ID)
SoftwareSource.branch_revision
- What patches were applied on top of it (A URL to the patchset, maybe?)
TBD, it's hard to say what those patches were. I would actually like a different solution, have the tree with pre-applied patches (so that we can still pinpoint the tree from git repo) and have a informative description of patches that were applied for other reasons. This would allow us to compare results of tests with and without a specific kernel patch (easy and interesting) withuot resorting to git bisections.
- What kernel config was used to build it (A separate file in the hwpack directory?)
Attachment to test run.
Best regards Zygmunt Krynicki