Oh, again...

Ok, instead of Christian Hopps, this time I'll explain.

> Recent discussions about programs requiring large VA space have
> reminded me that the amiga version of <machine/vmparam.h> has a
> value for USRSTACK that matches the sun3 port's value, with the
> comment that it is in hopes of compatibility with Sun3 binaries.
> The ability to run Sun3 binaries should not require the USRSTACK
> value from the sun3.  As evidence, the sun3x uses a different
> value of USRSTACK and can still run SunOS/sun3 binaries.

Yes yes. The comment is old and misleading.

> I suggest you bump up USRSTACK and VM_MAX_ADDRESS (etc.) to let
> user processes on the amiga have more VA space.  Something like
> 0xF8000000 would be reasonable, or 0xF0000000 if you expect to
> run on machines with more than 256MB of RAM.

Oh, to be expected soon. The average Amiga accellerator board can have
128 MB on-board, in addition to the mainboards 16 M, and a couple of
Zorro-III memory boards. And the Xserver wants to map in the framebuffer
address space, which is often very big, although the used space is only
4 MB (+ control registers) or less, in most cases. On the other hand...

Problem is, that the current PMAP implementation needs lots of kernel wired
down memory for large user address spaces. This needs to be fixed eventually
by rewriting the PMAP. Currently, using big spaces needs something like a whole MB ... and non-accellerated Amigas have 8 MB, if lucky.

Christian says, and nowadays I agree, that whoever has a big machine which
could handle big demands, and needs that space, can easily recompile his
kernel with bigger USRSTACK etc, in short time. However, people with just
a 68030 or '020 and 8 MB shouldn't be punished for that. 
(They will need much more time to rebuild their kernel, right?)

[In the special case which came up (again) recently (rpc.statd), I don't think
its database handling demands would require a big address space if sanely
written. We have a moderately useful database engine in libc which would 
handle 250000 host entries much better than sequentally searching through 
256 MB of address space (which rpc.statd did until yesterday), and I guess
nobody will be really sad that as an intermediate measure, until somebody
has time to rewrite that part of it, it can only handle 16000 hosts by
sequentially searching through 16 MB of address space.]

Regards,
	Ignatios