[[!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