There is a
master-x86_64 GNU Mach branch. As of 2012-11-20, it only supports
the Xen platform.
IRC, freenode, #hurd, 2011-10-16
<youpi> it'd be really good to have a 64bit kernel, no need to care about addressing space :) <braunr> yes a 64 bits kernel would be nice <braunr> i guess it wouldn't be too hard to have a special mach kernel for 64 bits processors, but 32 bits userland only <youpi> well, it means tinkering with mig <braunr> like old sparc systems :p <youpi> to build the 32bit interface, not the 64bit one <braunr> ah yes <braunr> hm <braunr> i'm not sure <braunr> mig would assume a 32 bits kernel, like now <youpi> and you'll have all kinds of discrepancies in vm_size_t & such <braunr> yes <braunr> the 64 bits type should be completely internal <braunr> types* <braunr> but it would be far less work than changing all the userspace bits for 64 bit (ofc we'll do that some day but in the meanwhile ..) <youpi> yes <youpi> and it'd boost userland addrespace to 4GiB <braunr> yes <youpi> leaving time for a 64bit userland :)
IRC, freenode, #hurd, 2012-10-03
<braunr> youpi: just so you know in case you try the master-x86_64 with grub <braunr> youpi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689509 <youpi> ok, thx <braunr> the squeeze version is fine but i had to patch the wheezy/sid one <youpi> I actually hadn't hoped to boot into 64bit directly from grub <braunr> youpi: there is code in viengoos that could be reused <braunr> i've been thinking about it for a time now <youpi> ok <braunr> the two easiest ways are 1/ the viengoos one (a -m32 object file converted with objcopy as an embedded loader) <braunr> and 2/ establishing an identity mapping using 4x1 GB large pages and switching to long mode, then jumping to c code to complete the initialization <braunr> 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 memory management.
<tschwinge> Or with a 64-bit one? ;-P <braunr> tschwinge: i think we all had that idea in mind :) <pinotree> tschwinge: patches welcome :P <youpi> tschwinge: sure, please help us settle down with the mig stuff <youpi> what was blocking me was just deciding how to do it <braunr> hum, what's blocking x86_64, except time to work on it ? <youpi> deciding the mig types & such things <youpi> i.e. the RPC ABI <braunr> ok <braunr> easy answer: keep it the same <youpi> sorry, let me rephrase <youpi> 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 <braunr> can't this be done in two steps ? <youpi> well, it'd mean revamping the whole kernel twice <youpi> as the types at stake are referenced in the whole RPC code <braunr> 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) <youpi> it's not so simple <youpi> the RPC code is tricky <youpi> and there are alignments things that RPC code uses <youpi> which become different when build with a 64bit compiler <pinotree> there are also things like int[N] for io_stat_struct and so on <braunr> i see <youpi> making the code wrong for 32 <youpi> thus having to change the types <youpi> pinotree: yes <pinotree> (doesn't mig support structs, or it is too clumsy to be used in practice?) <braunr> pinotree: what's the problem with that (i explcitely said changing int to e.g. int32_t) <youpi> that won't fly for some of the calls <youpi> e.g. getting a thread state <braunr> pinotree: no it doesn't support struct <pinotree> braunr: that some types in struct stat are long, for instance <braunr> pinotree: same thing with longs <braunr> youpi: why wouldn't it ? <youpi> that wouldn't work on a 64bit system <youpi> so we can't make it int32_t in the interface definition <braunr> i understand the alignment issues and that the mig code adjusts the generated code, but not the content of what is transfered <braunr> well of course <braunr> i'm talking about the first step here <braunr> which targets a 32-bits userspace only <youpi> ok, so we agree <youpi> the second step would have to revamp the whole RPC code again <braunr> i imagine the first to be less costly <braunr> well, actually no <braunr> 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 <braunr> (unless we keep a 3/1 split instead of giving the full 4g to applications)
See also memory management.
<youpi> (I don't see what that changes) <braunr> 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 <youpi> err, ok, but what's the point of the 64bit kernel then ? :) <braunr> and it simply uses 64-bits addresses to deal with physical memory <youpi> ok <youpi> that could even be a 3.5/0.5 split then <braunr> but the memory model forces us to run either at the low 2g or the highest ones <youpi> but linux has 3/1, so we don't need that <braunr> otherwise we need an mcmodel=medium <braunr> we could do with mcmodel=medium though, for a time <braunr> hm actually no, it would require mcmodel=large <braunr> 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
IRC, freenode, #hurd, 2013-07-02
In context of mondriaan memory protection.
<xscript> BTW, it's not like I have an infinite amount of time for this, but having 64-bit support would be valuable for me, so I might contribute that back if it's not a too monumental task <xscript> I saw some discussions about 32bit apps on top of 64bit mach, but I'd like a full 64bit system <xscript> any clues? <xscript> I suppose the compiler support is all there already <xscript> is MIG (and mach) the only piece missing? <braunr> the problem is the interfaces themselves <braunr> type widths <braunr> as passed between userspace and kernel