[RFC] Board status script (was: Change in coreboot[master]: Another pass at board status script)
Dear coreboot folks,
currently there are several patches in Gerrit for review introducing a board status script [1][2] and the output of Ron’s one [3][4].
Putting the board status data into the repository or somewhere else is great! The question remains what is needed exactly. Some things are already discussed in the review of David’s patch [2].
In my opinion, as log data is small, there is no problem getting much data, where it is unknown if it is needed or not in the future. The data should be gotten by a script and most of it machine parseable so regressions can be detected automatically.
What do you all need? Think of the regressions you had in the past and how these could be detected with such a script.
Does Ayush’s GSoC 2013 work include anything, we could use for this status script?
Am Sonntag, den 03.11.2013, 10:06 -0800 schrieb ron minnich:
The document you cite is not applicable. The issue here is not 'will coreboot work on my machine' but 'what is the status of a supported mainboard'. Those are two very different things.
there are a lot of intersections.
If you want to know what superio chip is on the board, for example, look at the config which is provided in the status.
Sure. But regarding the Super I/O we are also interested, if the register values changed. So getting `superiotool -deV` is useful in my opinion.
It's a git repo so I expect the log files get overwritten each time.
If we put it in the same repository, it would of course be useful for review as the diff would be shown in Gerrit. On the other hand it would be more difficult to compare different versions and as written in the review to commit tests from older changes.
And nobody should be pushing a status that includes a hash that is not available in a public repo.
The question is, how we enforce that.
The goal is to provide the minimum amount of information needed for a working mainboard, not a gigantic firehose of data. I even question the value of the dmesg log, given the huge variance in linux kernels out there, but we can do it for now.
It is better to get more data, when it is small, because you never know what it can be used for.
Thanks,
Paul
[1] http://review.coreboot.org/#/c/4011/ [2] http://review.coreboot.org/#/c/4021/ [3] http://review.coreboot.org/#/c/4005/ [4] http://review.coreboot.org/#/c/4010/ [5] http://blogs.coreboot.org/blog/author/ayushsagar/
Am 03.11.2013 23:55, schrieb Paul Menzel:
Putting the board status data into the repository or somewhere else is great! The question remains what is needed exactly. Some things are already discussed in the review of David’s patch [2].
"what is needed exactly" isn't the interesting question. "what is needed right now" is.
This isn't a government contracted project where every change leads to an explosion in budget. We don't even have a budget.
In my opinion, as log data is small, there is no problem getting much data, where it is unknown if it is needed or not in the future. The data should be gotten by a script and most of it machine parseable so regressions can be detected automatically.
I eagerly await your patches.
Patrick
well, now that this has come up here, I might as well put the full plan out.
The mainboard status repo needs repair.
We want to make a script that produces concise results that make it easy for a potential OEM to make a go/no-go decision. Right now, they can't do this, and we've been asked to fix tht problem.
The vendors want to know two things: - can I build it - will it boot [my os] -- where that may not be linux.
So we need a simple script that produces this information. It needs to be easy to run, have very few dependencies, and communicate the key information without drowning the user in a bunch of extraneous data.
How do we answer those questions?
We need to present results that are current. So, starting Nov. 15, the static mainboard status page will be more dynamic. The table will become a waterfall of tables, updated each week. Older results will be found in older tables.
So the 'Can I build it' will be answered by looking at the table. How will be answered by seeing what date a build was reported, getting the hash and config, and then trying to build it.
Will it boot can only be answered by trying to boot it, but the log might be helpful.
The huge amount of detail Paul is proposing doesn't help that much with these questions. This is not about regressions. This is about whether a board worked for someone. The mainboard status page is full of errors and if I could remove it today, I would.
And, again, the value of dmesg is quite overstated. Linux dmesg is so variable that for the most part it's one bit of information: 'got a dmesg/did not get a dmesg'.
What this means is we're going to make work for our community. If you have a working board, YOU need to run that script and push the results. The pressure to run the script will increase each week, as your results fall lower down on the waterfall :-)
hope this helps.
ron
-
Patrick Georgi -
Paul Menzel -
ron minnich