Andi, Andi Kleen wrote: > Borislav, >>>> year. You are refusing to work with other people on a well designed >> >> Sorry, but from our last discussion on attempting to work towards such >> an infrastructure solution I got the same impression as Thomas and Ingo >> that you're simply not willing to work together on getting a real thing >> done. That's why I stopped bothering - it simply made no sense to me to >> waste time in fruitless discussions. > > Well I keep ignoring suggestions to put more stuff into EDAC, > mostly because I think the EDAC design needs to be thrown out > instead of extended. Are you referring to that? > > My impression was that you got to the same conclusion (at least > for parts of current EDAC like the events) based on your earlier emails. > > The current issue is less in enumeration/topology anyways but more > in event handling I would say. In the end topology/enumeration is > the easier part, and most of it is already working quite well. > > I'm trying to do things step by step, including for short term > problems extending current interfaces if possible and then longer > term moving to new better interfaces. Ingo and Thomas are right: we need to work together to improve the error report, and this means that we shouldn't ignore putting more stuff in EDAC. EDAC is generic enough to work with different type of memory and memory controllers, and to provide a consistent interface to describe it on a way that userspace doesn't need to know what are the error registers at the hardware, nor how to decode a "magic" error number into something that has a meaning. As Boris properly pointed, EDAC has space for improvements, and part of the perf logic can be used as a start point to give some flash new ideas. The main issue I see with MCE is at the interface level. I think if we all cope together, we can converge into a proper interface that will be accepted upstream. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|