On Fri, 2013-10-18 at 18:25 -0500, Scott Wood wrote:
On Sat, 2013-10-19 at 01:07 +0200, Oliver Schinagl wrote:
On 10/18/13 18:43, Scott Wood wrote:
On Fri, 2013-10-18 at 02:04 +0200, Oliver Schinagl wrote:
So now that that's settled, anything fundamentally wrong with my patch? :)
Did you see my other mail in this thread? This patch is sort of OK for
Sorry I did and I got distracted from it.
raising the get_ram_size() limit from 1 GiB to 2 GiB (with an increased risk of false positives from I/O), but it can't go beyond that on
I'd ask 'how so' but I'm not sure I'd understand anyway ;)
Do you mean why it can't go beyond 2 GiB? The next address to probe after 0x8000_0000 would be 0x1_0000_0000 which is beyond what can be addressed in a 32-bit environment. I suppose you could return 4 GiB if 0x8000_0000 tests OK, but nothing beyond that. You'd need a larger datatype than "unsigned long" if you want to return 4 GiB, though.
Oh, and if you actually had 4 GiB of RAM mapped in a 32-bit environment, where would I/O go?
-Scott