> I get that we have to support v1 and v2 for backward compatibility, but for the point no.2 > made by Tony - > "2) Incremental systems that have both V1 and V2 interfaces.", > just wanted to understand if we expect any use case where if EINJ V2 is supported, both v1 > and v2 interfaces shall be required at the same time for error injection, as from the spec, > if V2 is supported, EINJV2_SET_ERROR_TYPE takes precedence. > > This seems to be similar with V1 action types - whether to go with SET_ERROR_TYPE_WITH_ADDRESS or > SET_ERROR_TYPE, is based on the action entry in the EINJ table where "SET_ERROR_TYPE_WITH_ADDRESS" > gets precedence. I don't think it will be required to support users mix and matching v1 and v2 in the middle of an injection. So will need some locking between the einj/error_inject and the einjv2/error_inject action phase. I'd still like to see the einjv2 injection supply all parameters in a single write to a debugfs file and have the driver parse the values. E.g. # echo "corrected memory 0x1234567890 notrigger" > /sys/kernel/debug/apei/einjv2/error_inject That would make injection a user-level atomic operation, and avoid all the confusion that results from updating the param1, param2, ... files individually. -Tony
