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

[Eric W. Biederman]

Andi Kleen <ak@xxxxxx> writes:

>
> 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. 

Yep we sometimes have to mess with complicated things.

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

Yep we sometimes have to mess with MMIO.

> 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.

Mostly.  Except for the part where you have to figure out the stepping
of the processor connected to the memory controller to properly decode
the registers.  AMD should have used the revision field in pci config
space but...

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

I agree it should be that simple. 

But if all of your drivers are not that simple it doesn't make sense
to put half of them in user space and half of them in the kernel,
unless there is a good reason for them not to be in the kernel.

Eric
-
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/