[coreboot] [RFC] Board status script (was: Change in coreboot[master]: Another pass at board status script)

[Paul Menzel]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20131103/ab5bf4f2/attachment.sig>