Andi Kleen <[EMAIL PROTECTED]> writes: > On Mon, Dec 04, 2006 at 05:45:58PM -0500, Vivek Goyal wrote: >> On Mon, Dec 04, 2006 at 10:42:47PM +0100, Andi Kleen wrote: >> > > > But arch independent code can not call __pa_symbol() as this definition >> > > > is local to i386 and x86_64 arches. So is it acceptable to change >> > > > symantics of __pa()? >> > >> > __pa is by definition architecture dependent. Why should >> > architecture independent code want to call it? >> > >> >> That's true, but a quick grep in drivers/ dir gave me lots of results. I am >> pasting few of them. Looks like __pa() is already being used at many a places >> in arch independent code > > Most of them should be using the DMA API > >> >> An stupid question, as __pa() is arch dependent call, how does one >> determine the physical addr associated with a kernel text sysmbol or phy >> addr associated with a kernel linearly mapped region in in arch independent >> code? > > You don't. Only architecture code is supposed to know anything > about that.
Right. There are two pieces to this answer. - For kernel text the physical addresses is totally unsupportable because we may be using text replication for better NUMA locality so there may be multiple physical addresses for the kernel text. Plus kernel should always be read only. - For kernel data the only practical use is to setup DMA. In most cases because you may have multiple instances of a device DMA'ing to static data is broken. I think the rest are simply not interesting enough to justify even using virt_to_page. As for __pa given the potential difference between bus addresses and physical addresses using that directly generically really is a bug. Shortly we will have x86_64 systems where you will have to go through an iommu for everything and the logic will be completely broken there. Eric _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
