Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: + edac-new-opteron-athlon64-memory-controller-driver.patch added to -mm tree | Date | Thu, 06 Jul 2006 13:09:35 -0600 |
| |
Andi Kleen <ak@muc.de> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |