[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 <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
> needs to become a "fixed" type, and something else needs to be created
> 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
Main Index |
Thread Index |