Hi Julius,
On 28.11.23 03:31, Julius Werner wrote:
Sounds to me like what you're asking for is really documentation, not a spec?
well, yes and no. It would be documenting what we did all along. But also serve as a blueprint for coreboot.
I'm not all set on the term. I think it fits, even if it isn't what low-level developers would expect. But it seems more impor- tant to define (if not specify) what we think a coreboot should look like.
Or maybe project-internal rules about what individual platform code may and may not do (but that's still not really a spec)?
In my understanding, a specification is always something defining a standard that allows interoperability _between_ different implementations.
It can be, but it can also be about interchangeability. When you specify a product, for instance, you may want different manufacturers to produce it, without making a difference for the consumer.
Something that only applies to a single implementation (i.e. a single code base) can't really be a specification.
But there are different implementations of coreboot. Every time some- body does a bigger experiment on a local branch, that's a different coreboot. Or would you say it's still a single implementation when it shares 50% of the code base? 20%? 10%?
Making a "coreboot specification" would mean that someone else could then take that and implement their own "coreboot" in a completely separate cleanroom code base from scratch, and I don't think that makes sense.
I don't like superlatives. I don't think it needs to be "completely separate". For instance, when somebody discusses coreboot for a new platform behind closed doors[1]. And they implement something on the same code base. If they did that according to spec, it would be more likely to get accepted upstream, wouldn't it?
Nico
(We could create a specification for the coreboot payload handoff interface (i.e. coreboot tables) so that other people could write their own firmware stack that can run coreboot payloads. I don't think that would make much sense, though. If we wanted payload interoperability we should probably rather attach to one of the various other "universal payload" proposals that were going around, although we've had discussions about that before where I at least argued that I don't think that makes much sense for coreboot.)
[1] Let's not discuss if that should happen.