summaryrefslogtreecommitdiff
path: root/open_issues/64-bit_port.mdwn
blob: 2d273ba1f63abfd249e5277fc4b777803ffd6117 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_gnumach open_issue_mig]]

There is a `master-x86_64` GNU Mach branch.  As of 2012-11-20, it only supports
the [[microkernel/mach/gnumach/ports/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 :)