Re: + edac-new-opteron-athlon64-memory-controller-driver.patchadded to -mm tree

[Alan Cox]

Ar Maw, 2006-07-04 am 13:34 +0200, ysgrifennodd Andi Kleen:
> > > Giving a consistent sysfs interface is a bit harder, but I suppose one 
> > > could change the code to provide pseudo banks for enable/disable too.
> > > However that would be system specific again, so a default "all on/all off" 
> > > policy might be quite ok.
> > 
> > I think we need the basic consistent sysfs case. Whether that is
> 
> What should i do?

Well personally I would favour the MCE logging stuff staying in because
its clearly small, compact and enough for many users, and the EDAC stuff
hooking that feed somehow so that people who want the detail and the
common behaviour across platforms can load the extra module.

As to filtering and control of the banks - that can always be done by
filtering what is handed down from the MCE code if I understand it right
so can be left in the EDAC side.

But thats just my opinion. It is based on what I'm seeing in terms of
feedback from people using EDAC a lot (eg in clusters). 

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/