Re: paddr_t change to 64-bits

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On Tue, 28 Sep 2010 10:42:43 +0700, Robert Elz <kre%munnari.OZ.AU@localhost> 
wrote:
> Date:        Tue, 28 Sep 2010 01:51:04 +0200
>     From:        Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>
>     Message-ID:  <4CA12DE8.1080706%free.fr@localhost>
> 
>   | Using paddr_t is unfortunate there:
> 
> It isn't "unfortunate", it's wrong, if paddr_t isn't going to remain a
> constant type for the life of an API (that is, if just switching kernel
> options can change it) then it must be kept completely out of the API
> (ie: nothing, with the possible exception of libkvm, which can almost be
> considered a kernel adjunct) can be allowed to use it for anything.
> 
> If its usage is already too embedded for that to be possible, then
paddr_t
> needs to become a "fixed" type, and something else needs to be created
to
> be
> be used as the data type for addresses shose size varies depending upon
> the whim of whoever booted the most recent kernel.

In the long run, paddr_t will be a fixed size for i386: 64 bits.

However, we are in transition here: I cannot virtually double paddr_t size
(4 => 8 bytes) without carefully checking that it does not affect code,
especially the parts that are performance critical: pmap(9),
bus_space/dma(9),
and all subsystems that rely on pool_cache(9) and its caches (pretty much
everything these days).

IMHO, the easiest way to fix agp_allocation there is to make "physical" an
uint64_t
only at this interface (and only for i386...), and wait for the situation
to settle by itself when I'll commit the "paddr_t is 64 bits" in kernel
for i386.

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost