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. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
