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/
This archive was generated by hypermail 2b29 : Tue May 14 2002 - 12:00:12 EST