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
|
[[!meta copyright="Copyright © 2011, 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 faq/support]]
[[!meta title="Doing a GNU/Hurd System Port"]]
How difficult is it to port the GNU/Hurd system to run on another architecture?
The GNU/Hurd system consists of [[/Hurd]] servers running as user-space
processes on top of the [[GNU Mach|microkernel/mach/gnumach]] microkernel. The
system functionality is usually accessed through the
[[POSIX|posix_compatibility]] interface that is provided by [[/glibc]] and
[[/libpthread]].
A whole-system port involves touching all these components, with varying
degree, of course.
For a CPU architecture port, the microkernel is the most involved part,
followed by glibc and the threading library.
The original [[microkernel/Mach]] microkernel was portable to a number of
architectures which were a lot more popular at the beginning of the 1990s than
they are now.
The GNU/Hurd system is currently available for the x86 architecture. This
includes emulators such as [[hurd/running/QEMU]] (or KVM), or
[[hurd/running/VirtualBox]]. Besides this, there is a port for the [[Xen
domU|microkernel/mach/gnumach/ports/xen]] *sub-architecture*.
Further on, there are some [[unfinished porting
attempts|microkernel/mach/gnumach/ports]] for the Alpha, MIPS and PowerPC
architectures. These have not been completed due to little developer interest.
Another option is to do the port at a different layer: port the Hurd servers to
not run on the GNU Mach microkernel, but instead on top of [[another
microkernel|which_microkernel]]. Or, even by providing a Mach emulation layer
on top of a monolithic kernel. For example, there could be a port for [[having
Mach run as a POSIX user-space process|open_issues/mach_on_top_of_posix]], or
by implementing the [[Mach IPC|microkernel/mach/ipc]] facility (as well as
several others) as Linux kernel modules. While there have been some
experiments, no such port has been completed yet.
# IRC, freenode, #hurd, 2013-09-05
<rah> what would be required to port the hurd to sparc?
<pinotree> port gnumach, write the sparc bits of mach/hurd in glibc, and
maybe some small parts in hurd itself too
<rah> what would be required to port gnumach? :-)
<braunr> a new arch/ directory
<braunr> bootstrap code
<braunr> pmap (mmu handling) code
<braunr> trap handling
<braunr> basic device support (timers for example)
<braunr> besides, sparc is a weird beast
<braunr> so expect to need to work around tricky issues
<braunr> in addition, sparc is dead
<rah> mmm
<rah> it's not totally dead
<rah> the T1 chips and their decendents are still in production
<rah> the thing is I'd like to have real hardware for the hurd
<rah> and if I'm going to have two machines running at once, I'd rather one
of them was my UltraSPARC box :-)
<braunr> rah: unless you work hard on it, it's unlikely you'll get it
<rah> braunr: of course
|
