On Mon, Oct 4, 2010 at 10:59 PM, David Hendricks david.hendricks@gmail.com wrote:
On Mon, Oct 4, 2010 at 12:23 PM, Peter Stuge peter@stuge.se wrote:
phorsyon wrote:
a minimal and a consumer version of a certificate
As was mentioned, the more certifications there are, the less easy it is for the market to make use of them.
I don't think we can afford to try to market two different certifications. I would only like to try for one; "consumer coreboot" or rather; "coreboot complete"
Developers don't want problems any more than average users just because they may know how to deal with problems.
Anyway, if we would have criteria then we could also track them.
Any interested developer could easily discover what was missing for a board to be coreboot complete, judge if it is a good choice for them at the moment, and if not just look for completeness of other boards.
I agree with Peter here, and will add my $0.02 to the thread... Certification is a *huge* process, at least if you want it to mean anything. I would expect that a true certification effort would rival development of the code itself. Multiple levels of certification only complicate the process and confuse users. And quite honestly, I don't expect that to happen unless a lot of dedicated resources are poured into it.
Agreed.
Perhaps the best thing is simply to publish a giant testing matrix for each board.
This would certainly be a huge improvement. Maybe this should be our actual first step?
Certify against the absolute bare minimum technical requirements, ie, can all on-board devices be initialized by firmware, are SMBIOS tables populated, etc.
I actually fully agree with this. However, we would need some way to tell if things like the SMBIOS tables are populated. That means that we'd need some form of software to run after the coreboot step to verify. Since we don't have a piece of software that is only that, how do we test for certification? I see a couple options: * don't certify anything until we develop a coreboot confirmation payload of some type * certify based on some software stack that we can currently use
Given that I don't see a coreboot confirmation payload being developed overnight, I would think that we should start with some software stack that we can currently use. In my eyes, this means using some easy to obtain Linux distribution and a bit of software to test compliance with some set of standards.
How would others solve the problem of testing for compliance?
Leave it up to the system builder to decide whether or not if it's usable for the application.
Agreed.
Maybe someone (FSF?) wants to create a higher-level standard that includes Coreboot along with a full free software stack, but that shouldn't be key to Coreboot certification at any level or you risk alienating major commercial partners.
Agreed. I wasn't trying to place a higher-level standard like "Works with Linux." I was trying to find the lowest barrier way to test for some minimum level of compliance.
Heck, everyone in the Coreboot community ought to be flattered if a major OEM ships a "Made for Win7" computer with Coreboot on it. Certify stuff that you know, leave everything else up to vendors.
I think this is one of the best perspective statements in this thread so far. :)
Thanks, wt