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 <[email protected]> NetBSD: 26 ans d'experience feront toujours la difference --
