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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
[[!meta copyright="Copyright © 2011, 2012, 2013 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 :)
# IRC, freenode, #hurd, 2012-12-12
In context of [[microkernel/mach/gnumach/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 [[microkernel/mach/gnumach/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
|
