Re: Use of __pa() with CONFIG_NONLINEAR

[Martin J. Bligh]

>> So, for CONFIG_NONLINEAR, we introduce a new indirection layer for
>> virtual to physical conversions (and the inverse as well).  Our
>> implementation uses some data structures to do this (patch is here:
>> http://lwn.net/Articles/79124/), and the side-effect is that we can't
>> use __pa() or __va() until after the initialization has run, which is
>> early in setup_arch().
>> 
>> But, there are quite a few things that obviously need physical addresses
>> earlier than that, such as cr3 initialization at compile-time.  So, in
>> Dave McCracken's patch, he introduced a new function: __boot_pa() that
>> does what the old __pa() did.
>> 
> 
> As Joel Stated in another note, I think documentation/comments is a must.
> My 'guess' is that anyone writing early init code is going to have a
> difficult time here.  As you stated the memsection initialization would
> happen in setup_arch().  For arch independent code this makes it pretty
> straight forward as everything run before the setup_arch() can use
> the old/offset method of calculating physical addresses and everything
> after can use the new method.  However, the arch specific initialization
> code is more difficult as it depends on where the call paths are relative
> to setup/alloc_memsections within setup_arch().
> 
> When I was trying to get nonlinear working on a specific architecture,
> I made the routines go through 'pointer to functions' and had the memsections
> initialization code modify the pointer after initialization was complete.
> In this way, I got the nonlinear code code up and working without changing
> all the early __pa/__va calls.  Obviously, this is a hack that should not
> be used as it introduces another level of indirection to performance
> critical code.  However, it was easy and saved me the effort of all that
> code inspection. :)

Can someone explain the necessity to create the new address space? We don't
need it with the current holes between nodes, and from my discssions with
Andy, I'm now unconvinced it's necessary.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/