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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux