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 
> port.
>
> 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. 
> ioctls).
>
> 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 
virtual addresses.

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.

Eduardo