Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 6 Oct 2001 10:45:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 6 Oct 2001 10:45:48 -0400 Received: from adsl-64-109-89-110.chicago.il.ameritech.net ([64.109.89.110]:13134 "EHLO localhost.localdomain") by vger.kernel.org with ESMTP id ; Sat, 6 Oct 2001 10:45:29 -0400 Message-Id: <200110061445.f96Ej5S01591@localhost.localdomain> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: paulus@samba.org cc: "David S. Miller" , jes@sunsite.dk, James.Bottomley@HansenPartnership.com, linuxopinion@yahoo.com, linux-kernel@vger.kernel.org Subject: Re: how to get virtual address from dma address In-Reply-To: Message from Paul Mackerras of "Sat, 06 Oct 2001 22:18:42 +1000." <15294.63138.941581.771248@cargo.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Oct 2001 09:45:05 -0500 From: James Bottomley Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org paulus@samba.org said: > I look at all the hash-table stuff in the usb-ohci driver and I think > to myself about all the complexity that is there (and I haven't > managed to convince myself yet that it is actually SMP-safe) and all > the time wasted doing that stuff, when on probably 95% of the machines > that use the usb-ohci driver, the hashing stuff is totally > unnecessary. I am talking about powermacs, which don't have an iommu, > and where the reverse mapping is as simple as adding a constant. > That was my second argument, which you didn't reply to - that doing > the reverse mapping is very simple on some platforms, and so the right > place to do reverse mapping is in the platform-aware code, not in the > drivers. On other platforms the reverse mapping is more complex, but > the complexity is bounded by the complexity that is already there in > drivers like the usb-ohci driver. This is precisely my point as well: You've made all the drivers that must be able to do this type of mapping assume the worst case because we cannot now have any window into the iommu if there is one. Worse still, every driver that needs this feature is doing it on its own, so the code for doing this in usb-ohci is different from the code in the sym53c8xx driver etc. We're now duplicating this fairly subtle and complex code all over the driver base. At the very least, providing an API to do this will get us away from all the error prone duplication. And if it's going to be an API, it might as well be architecture specific and iommu aware so it functions in the simplest and fastest way. davem@redhat.com said: > The argument against it is that if you provide such an easy way out, > people will just blindly transform bus_to_virt/virt_to_bus without > considering more straightforward methods when they exist. > I can not even count on one hand how many people I've helped > converting, who wanted a bus_to_virt() and when I showed them how to > do it with information the device provided already they said "oh wow, > I never would have thought of that". That process won't happen as > often with the suggested feature. I agree that some people are very prone to abusing the tools provided to them. I cannot agree that this is a good reason not to provide the tools in the first place. This is the type of argument usually heard from lawmakers and politicians. The linux community is better than that: we have a review process for new drivers. We even have a bunch of people who trawl through the old code looking for mistakes and problems who would probably be more that willing to send in patches for abuse of this API. Can we not educate the community (document the API properly) and rely on it to make the correct choices? James Bottomley - 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/