Re: [PAE support] Types + cosmetic fixes

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, Feb 24, 2010 at 12:18:13AM +0100, Jean-Yves Migeon wrote:
> On 02/23/10 20:15, Manuel Bouyer wrote:
> > On Tue, Feb 23, 2010 at 04:57:55PM +0100, Jean-Yves Migeon wrote:
> >> Yep, i386-pae. IMHO, modules cannot be "safely" shared between PAE and
> >> non-PAE.
> >
> > Yes. And I don't think making paddr_t 64bits unconditionally would
> > make them magically compatible for modules. There would be other issues.
>
> Should there be a "machine" (uname -m) defined with the following strings?
>
> i386
> i386-pae
> i386-xen
> i386-xen-pae
> amd64
> amd64-xen

I'm not sure what the effect to configure and similar scripts would be.
If this is for modules, I think this needs more though. I suspect some
kernel build options can also cause ABI changes which can cause modules
to fail, so modules should really be per kernel (at last for now, once
we have a documented API useable by modules, this can be rediscussed).


> >> There is much more work for in-kernel code though; for example,  
> iterating
> >> through the PDs/PTs is not as easy as iterating in a paddr_t array
> >> (consider a 64-bits paddr_t with a non-PAE kernel). We would have to  
> split
> >> pd_entry_t from paddr_t, which is currently not the case.
> >
> > Sure, you can't change the hardware to make the formats the same :)
> > I don't know if anything outside kernel tries to read the PTE though.
>
> I am more worried about parts of code which happily use paddr_t as  
> pd_entry_t (they should be limited to pmap though).

Yes.

> But this doesn't tell me: should I go the "typdef uint64_t paddr_t"  
> route? This may have unexpected overhead (which I cannot assess), and  
> might consume extra stack/register just to store bytes which will never  
> be used in non-PAE situation.

I don't think it's worth it right at this time.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--