Re: Bug: Discontigmem virt_to_page() [Alpha,ARM,Mips64?]

Roman Zippel (zippel@linux-m68k.org)
Fri, 10 May 2002 01:00:12 +0200


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/