Messages in this thread | | | Date | Fri, 10 May 2002 01:00:12 +0200 | From | Roman Zippel <> | Subject | Re: Bug: Discontigmem virt_to_page() [Alpha,ARM,Mips64?] |
| |
Hi,
Daniel Phillips wrote:
> On Friday 10 May 2002 00:06, Roman Zippel wrote: > > 1. My patch only modifies init code, I don't think it's really a problem > > if it's slightly slower. > > But why be slower when we don't have to. And why slow down *all* architectures? > > > 2. Above can now be written as "page = pfn_to_page(i + > > (bdata->node_boot_start >> PAGE_SHIFT))". Nice, isn't it? :) > > page++ is nicer yet.
Is memmap[i++] so much worse? Let me repeat, this is only executed once at boot!
> > Why do you want to introduce another abstraction? > > The abstraction is already there. I didn't create the logical space, I identified > it.
And it's called virtual address space.
> There are places where the code is really manipulating logical addresses, not > physical addresses, and these are not explicitly identified. This makes the code > cleaner and easier to read.
_Please_ show me an example.
> Look at drivers/char/mem.c, read_mem. Clearly, the code is not dealing with > physical addresses. Yet it starts off with virt_to_phys, and thereafter works > in zero-offset addresses. Why? Because it's clearer and more efficient to do > that. The generic part of my nonlinear patch clarifies this usage by rewriting > it as virt_to_logical, which is really what's happening.
Are we looking at the same code??? Where is that zero-offset thingie? It just works with virtual and physical addresses and needs to convert between them.
> That's really what's happening in bootmem too.
That also works with just physical and virtual addresses. What are you talking about???
bye, Roman - 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/
| |