Re: Use of __pa() with CONFIG_NONLINEAR

[Mike Kravetz]

On Tue, Jul 27, 2004 at 03:00:30PM -0700, Dave Hansen wrote:
> 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. :)

-- 
Mike
-
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/