Hi, > > As far I know there is no policy on that written down somewhere. In > > general we try avoid breaking backward compatibility (and thus requiring > > lockstep updates). But maintaining backward compatibility has a cost > > too, so this isn't set in stone. > > Sure, but backwards compatibility is highly valuable, so will offset > quite some cost. See Windows or the Linux kernel ABI.
Well, depends ... The linux kernel's userspace ABI maintains backward compatibility, yes. And there is countless software in the world depending on that. Still there are exceptions (see cgroups move from v1 to v2). Note that the linux kernel's in-kernel interfaces are explicitly *not* backward compatible though. > Here we are talking about a firmware compatibility, arguably even > more valuable than a kernel ABI, because firmware often, and > ironically this is probably no less true for coreboot than IBV > products, simply can not be updated. > > I expect payloads to value backwards compatibility quite high. I fail to see the problem. seabios is part of the firmware, users are not going to freely mix and match versions. So if you are stuck with an old coreboot version for whatever reason, just continue using an old seabios version. It's not like seabios does see heavy development, and the changes going in are mostly for new hardware support (recent example is nvme) which doesn't buy you much on old machines. > > > > Keeping backward compatibility with the "cbfs master header" would > > > > complicate the code. > > > > > > Obviously, but is undeniably valuable, even if not to you. > > > > Well, maintaining compatibility with a version released more than five > > years ago isn't that valuable IMHO, but comes with the cost of adding > > compatibility code which most likely will never ever be actually used. > > I know that five years is forever in QEMU, Well, we are at eight years right now, maintaining backward compatibility to qemu 1.4, released in Feb 2013. Compatibility code for older versions has been dropped (last year I think). Which reminds me that we can drop CONFIG_ACPI_DSDT + dependencies from seabios. > and perhaps in particular at Red Hat. ? > Firmware is not QEMU. Note that coreboot apparently considers 5 years of backward compatibility enough. They supported both old and new method for finding cbfs that long. take care, Gerd _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
