Re: paddr_t change to 64-bits

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

On Tue, 28 Sep 2010 18:50:46 +0700, Robert Elz <kre%munnari.OZ.AU@localhost> 
wrote:
> Date:        Tue, 28 Sep 2010 10:49:51 +0200
>     From:        Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>
>     Message-ID:  <2741c3f0cdb111bbb7077e25f6b47dc5@localhost>
> 
>   | In the long run, paddr_t will be a fixed size for i386: 64 bits.
> 
> Do you really want to decide that yet?

There is no other choice -- how can you expect kernel modules to be
shared between PAE and !PAE systems then?

Splitting i386 in two machine archs, "i386" and "i386pae"? Then we would
also have "i386xen", "i386xenpae". Huh...

>   | IMHO, the easiest way to fix agp_allocation there is to make
>   "physical" an
>   | uint64_t
> 
> exactly - uint64_t or agp_addr_t (a newly invented type just for the
> purpose perhaps) or something - but something unrelated to the internal
> kernel data type (except being certainly big enough).

As I said in another mail, I do think that paddr_t should be the
standard for interfaces. For i386, it has to be 64 bits. Implementing
optimizations (eg. use 32 bits operations unless strictly required) will
be the responsibility of certain code blocks (pmap, bus_dma/space,
pool_cache tracking...), and shall use types that are kept private to
these blocks.

> That one I can't comment on, if it is the only place that there's
> any movement of "phycical" addresses then it makes sense.
>[snip]
> but I'd hesitate before being sure that's the right solution - unless
> there's a very good reason, don't add machine dependent API interfaces.
> I know this is in a fairly MD area anyway, so I'm not certain that i386
> only is the wrong choice, and if the API is already inherently MD, that
> would make a difference - but otherwise, the benefits in having a single
> API for all users far outweighs the cost of passing a few useless bytes
> over the user/kernel interface - especially for something like this
> which I suspect is not anywhere on the high usage path.

True. But a physical address is not something you expect to change for
an architecture; PAE is more an exception that the rule. Having PAE
enabled should only affect very specific parts of the kernel, and should
not be visible from the outside, or even from modules (in a perfect
world). Sadly, currently, paddr_t makes the abstraction leaky.

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