Subject: Re: question regarding different p_addr_t
To: Garrett D'Amore <firstname.lastname@example.org>
From: Eduardo Horvath <email@example.com>
Date: 10/26/2005 16:02:51
On Tue, 25 Oct 2005, Garrett D'Amore wrote:
> For reasons I won't go into here, I need to increase the size of paddr_t on
> the Alchemy processors, which are currently covered by the evbmips port.
> The question is whether changing this size creates the need to for a new
> It seems like this data type (paddr_t) is used in few different places (e.g.
> struct mbuf).
> Changing the size to 64-bits leaves a working kernel, and -- as far as I can
> tell -- the evbmips userland built with it set for 32-bit also seems to work.
> What I'm not confident is kernel memory grovelers and debuggers.
> Is there a reason to believe that a kernel with this type at 64-bits should
> not be used with a userland compiled for it at 32-bits?
> Interestingly enough, it appears that there is at least one case where a
> 64-bit MIPS kernel is used with a 32-bit MIPS userland. I'm guessing that
> this is an indication that type mismatches between userland and the kernel
> are OK as long as they aren't in structures exposed to userland (e.g.
> Any thoughts or advice on this matter is appreciated. Thanks!
The whole paddr_t thing was added when I got the sparc64 port up in 32-bit
mode. It was needed to handle >32-bit physical addresses but 32-bit
As you said, you will get some possible breakage from certain memory
grovellers that examine structures with paddr_t's in them. But most
of the more important utilities that used to do kernel grovelling,
such as `ps' have already been converted to use sysctl to get data
from the kernel and are thus not affected by the issue.
You probably want to create a new $MACHINE but not necessarily a new
architecture ($MACHINE_ARCH). Also, additional support in the build
and installation infrastructure to allow $MACHINE specific versions of
memory grovellers such as netstat and vmstat would be a good thing.
That would also go a long way to supporting pure 32-bit (sparc or x86)
userlands on a 64-bit (sparc64 or amd64) kernels without having the
overhead of a whole 64-bit userland as well.