On Tue, Oct 31, 2017 at 3:05 PM, Jerry Hoemann <jerry.hoemann(a)hpe.com> wrote:
On Tue, Oct 31, 2017 at 02:42:01PM -0700, Dan Williams wrote:
> Yes, this can happen. However, for the kernel implementation it
> decide to move to rev-id2 at its leisure since ACPI mandates that
> rev-id1 implementations stick around, and if the function number was
> reserved in rev-id1 the kernel will already not support it.
Unfortunately, we can't do that. The kernel will still need to support
firmware that only knows about Rev ID 1.
Example, HPE currently supports customers w/ NVDIMMS with DSM that only
responds to rev id 1.
Say in the future we ship a new generation of NVDIMMs
that extends the DSM health function. We could make that
additional info available only for rev id 2. If the table
above were extended to call health function with rev id 2
so that we get the additional info for the new nvdimm, that
call will stop working on what will then be legacy systems
that only know rev id 1.
Right, I'm explicitly not supporting that degree of compatibility
freedom. If a platform wants to change the payload of an existing
function it had better expand the payload with new information that
can optionally be ignored by older kernels rather than spin the revid.
The kernel can't break legacy and neither should the platform, either
the kernel can call revid1 forever, the function is only available in
revid2 or later, or that function number is burned and we need to live
with the breakage that the platform shipped.
We are already in this position with the "smart threshold" payload
that has been broken in recent revisions of the Intel spec. In this
specific case we have ndctl binaries in the wild that are broken, but
are somewhat saved by the fact that the interface for *setting* alarms
and thresholds is brand new in v1.6. So my plan is to document that
smart threshold is broken and require new ndctl binaries with v1.6
support to implement the new format via the ND_CMD_CALL interface. The
fact that this compatibility management is on a case by case basis and
somewhat painful is a feature. Platform implementations must hide DSM
update thrash from the kernel and shipping binaries as much as