Re: [PAE support] Types + cosmetic fixes

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

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

>> 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).

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.

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