Bug #14660

Updated by Patrick Mooney 4 months ago

While the kernel interface to bhyve (the vmm portion) is considered Private, there are external projects (such as "Propolis": which consume it.    They choose to bear the cost of tracking the bhyve interface, sometimes encountering breakage when otherwise incompatible updates are made.    If bhyve were to publish an "interface version", exposed as a simple numeric value which increases monotonically as changes are made to the userspace/kernel interface, then those consumers could at least throw their hands up with an appropriate error when a mismatch was detected.    This is contrast to the situation today, where changes to the interface result in behavior which can be quietly broken, or that fails in seemingly strange ways. 

 I propose that this version number be made available via a dedicated ioctl on the @/dev/vmmctl@ device.    Like the rest of the bhyve kernel interface, the new ioctl would still be considered Private from a stability standpoint.    There would be no implied contract for how/when to update the exposed version.    It would be incremented on a best-effort basis by those making changes to bhyve kernel interfaces.