Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: paddr_t change to 64-bits

On Tue, 28 Sep 2010 10:42:43 +0700, Robert Elz <kre%munnari.OZ.AU@localhost> 
> Date:        Tue, 28 Sep 2010 01:51:04 +0200
>     From:        Jean-Yves Migeon <>
>     Message-ID:  <>
>   | 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
> needs to become a "fixed" type, and something else needs to be created
> 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),
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
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

Home | Main Index | Thread Index | Old Index