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

[Andi Kleen <ak@muc.de>]

On Thu, Jul 06, 2006 at 07:34:58PM +0100, Alan Cox wrote:
> Ar Iau, 2006-07-06 am 20:08 +0200, ysgrifennodd Andi Kleen:
> > > No. There is a status report that tells you which pieces of hardware
> > > your memory controller sees.  It is just a simple list.
> > 
> > Ok but that could be also done easily in user space that reads
> > PCI config space. No need for a complicated kernel driver at all.
> 
> The same is true of writing a file system and disk driver so I'm a bit
> confused why you think poking around in PCI space from user space is an
> argument or given how often such stuff breaks and how messy it gets (eg
> X) that we want to encourage it

It depends on what you do. First a large part of X's messiness
comes from it not using the proper interfaces.
Or it trying to do complicated things like messing with bridges. 

Then anything with MMIO or interrupts or anything dynamic 
definitely belongs into kernel space agreed.

But at least on K8 DIMM inventory is purely reading PCI config space on
something that doesn't change and doesn't need any locking. 
It also doesn't need to do anything complicated, but just look
for the right PCI ID.

I don't see an issue with such simple static things in user space.

I could probably write it as a shell script that parses lspci output
(not saying that that would be the right way, but it's certainly
doable)

-Andi