blob: 797d540f8a5d6ed3e286d117d22a4ecb65d35ba1 (
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
|
[[!meta copyright="Copyright © 2011 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]]
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 :)
|
