[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PAE support] Types + cosmetic fixes
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?
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,
> >> 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
> >> 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.
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
Main Index |
Thread Index |