From 51c95fc11727532e3b0d98c8470a6b60907a0680 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 8 Jan 2013 21:31:31 +0100 Subject: IRC. --- open_issues/64-bit_port.mdwn | 80 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) (limited to 'open_issues/64-bit_port.mdwn') diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn index 2d273ba1..66da44b9 100644 --- a/open_issues/64-bit_port.mdwn +++ b/open_issues/64-bit_port.mdwn @@ -57,3 +57,83 @@ the [[microkernel/mach/gnumach/ports/Xen]] platform. and switching to long mode, then jumping to c code to complete the initialization i think i'll go the second way with x15, so you'll have the two :) + + +# IRC, freenode, #hurd, 2012-12-12 + +In context of [[microkernel/mach/gnumach/memory_management]]. + + Or with a 64-bit one? ;-P + tschwinge: i think we all had that idea in mind :) + tschwinge: patches welcome :P + tschwinge: sure, please help us settle down with the mig stuff + what was blocking me was just deciding how to do it + hum, what's blocking x86_64, except time to work on it ? + deciding the mig types & such things + i.e. the RPC ABI + ok + easy answer: keep it the same + sorry, let me rephrase + decide what ABI is supposed to be on a 64bit system, so as to know + which way to rewrite the types of the kernel MIG part to support 64/32 + conversion + can't this be done in two steps ? + well, it'd mean revamping the whole kernel twice + as the types at stake are referenced in the whole RPC code + the first step i imagine would simply imply having an x86_64 + kernel for 32-bits userspace, without any type change (unless restricting + to 32-bits when a type is automatically enlarged on 64-bits) + it's not so simple + the RPC code is tricky + and there are alignments things that RPC code uses + which become different when build with a 64bit compiler + there are also things like int[N] for io_stat_struct and so on + i see + making the code wrong for 32 + thus having to change the types + pinotree: yes + (doesn't mig support structs, or it is too clumsy to be used in + practice?) + pinotree: what's the problem with that (i explcitely said changing + int to e.g. int32_t) + that won't fly for some of the calls + e.g. getting a thread state + pinotree: no it doesn't support struct + braunr: that some types in struct stat are long, for instance + pinotree: same thing with longs + youpi: why wouldn't it ? + that wouldn't work on a 64bit system + so we can't make it int32_t in the interface definition + i understand the alignment issues and that the mig code adjusts + the generated code, but not the content of what is transfered + well of course + i'm talking about the first step here + which targets a 32-bits userspace only + ok, so we agree + the second step would have to revamp the whole RPC code again + i imagine the first to be less costly + well, actually no + you're right, the mig stuff would be easy on the application side, + but more complicated on the kernel side, since it would really mean + dealing with 64-bits values there + (unless we keep a 3/1 split instead of giving the full 4g to + applications) + +See also [[microkernel/mach/gnumach/memory_management]]. + + (I don't see what that changes) + if the kernel still runs with 32-bits addresses, everything it + recevies from or sends through mig can be stored with the user side + 32-bits types + err, ok, but what's the point of the 64bit kernel then ? :) + and it simply uses 64-bits addresses to deal with physical memory + ok + that could even be a 3.5/0.5 split then + but the memory model forces us to run either at the low 2g or the + highest ones + but linux has 3/1, so we don't need that + otherwise we need an mcmodel=medium + we could do with mcmodel=medium though, for a time + hm actually no, it would require mcmodel=large + hum, that's stupid, we can make the kernel run at -2g, and use 3g + up to the sign extension hole for the kernel map -- cgit v1.2.3