+Mauro
On 6/24/2015 1:12 PM, Luck, Tony wrote:
"Memory Error Section 2". One option we have without having to disturb user space handler of memory error trace data would be to change "struct cper_mem_err_compact" so the affected elements are of __u32 instead of __u16. Drawback of this option is that the trace buffer will be unnecessarily bigger if a platform generates "Memory Error Section" data instead of "Memory Error Section 2" data.
That structure is visible to user level consumers of the event (perhaps just one of those right now?):
git://git.fedorahosted.org/rasdaemon.git
We were not as smart as UEFI and didn't include a version number, or other plan, that would allow us to transition to a new format cleanly.
Perhaps we could re-purpose some of the high order "validation_bits" as a version number? It's a u64 and UEFI 2.5 is only up to bit21 so far, so perhaps it will be a long, long time before they get that many fields in some future standard.
I agree that we could re-purpose some of the high order "validation_bits" as a version number. That being said, I am not sure whether that approach is preferred by user space tool authors. My feeling is such approach would make user space tool more complicated (eg. has to understand versions). Mauro, pls. correct me is I am wrong; pls. refer to previous email in this thread for context related to challenge brought forth by UEFI 2.5.
perf interface has debugfs interface, so if user space tool does following, compatibility with different kernel version and different spec version will be maintained: * Use debugfs interface to discover format of trace data. * use largest size known for user space structure; check size of member in user space structure and size of corresponding field in trace data, adjust data as necessary.
In the mean time, I think when kernel defines TRACE_EVENT, it should try not having to use __field_struct, that would make format inside that field opaque to user space tool. For instance: __field_struct(struct cper_mem_err_compact, data) Because of above, ras-extlog-handler.c in rasdaemon has to hardcode this structure, making it harder to maintain forward/backward compatibility.