14 files changed, 329 insertions, 0 deletions
diff --git a/faq/support/0-drivers.mdwn b/faq/support/0-drivers.mdwn
new file mode 100644
index 00000000..974fb612
--- /dev/null
+++ b/faq/support/0-drivers.mdwn
@@ -0,0 +1,18 @@
+[[!meta copyright="Copyright © 2009, 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]]."]]"""]]
+
+[[!meta title="What drivers does GNU/Hurd have?"]]
+
+Currently, for disks Mach integrates drivers from Linux 2.0 through some
+[[community/gsoc/project_ideas/driver_glue_code]].  As it's very old, that
+limits hardware support a lot, of course.  For network boards, we use the
+[[DDE]] toolkit to run linux 2.6.32 drivers in userland processes,
+which provides both long-term support for new hardware and safety against driver
+bugs.
diff --git a/faq/support/0-software.mdwn b/faq/support/0-software.mdwn
new file mode 100644
index 00000000..324dbbef
--- /dev/null
+++ b/faq/support/0-software.mdwn
@@ -0,0 +1,16 @@
+[[!meta copyright="Copyright © 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2010,
+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]]."]]"""]]
+
+[[!meta title="What software is available for GNU?"]]
+
+  * Most (3/4) packages from [Debian](http://www.debian.org/) [GNU/Linux](http://www.gnu.org/gnu/linux-and-gnu.html) which aren't linux-specific ([Packages That Won't Be Ported](http://www.debian.org/ports/hurd/hurd-devel-debian)) are expected to work on GNU/Hurd too. See the database in <http://packages.debian.org/>. Notably, [GNOME](http://www.gnome.org), and [KDE](http://www.kde.org) work. See the [[porting/guidelines]] document for some common build problems and their solutions.
+  * If you can't fetch a package with "apt-get install ", try building it from source: "apt-get source  &amp;&amp; cd &lt;package\_dir&gt; &amp;&amp; debian/rules binary".
+  * As of March 2013, 78% of Debian packages have been ported on the Hurd. Of course, bug testing is welcome.
diff --git a/faq/support/2_gib_partition_limit.mdwn b/faq/support/2_gib_partition_limit.mdwn
new file mode 100644
index 00000000..3d502a17
--- /dev/null
+++ b/faq/support/2_gib_partition_limit.mdwn
@@ -0,0 +1,16 @@
+[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]]
+
+[[!meta title="Is there still a 2 GiB Partition Limit?"]]
+
+The 2 GiB limit has been removed in Debian GNU/Hurd.
+
+Disk drivers however currently do not support more than 2^32 sectors, i.e. 2TiB.
diff --git a/faq/support/64-bit.mdwn b/faq/support/64-bit.mdwn
new file mode 100644
index 00000000..ab95d9d0
--- /dev/null
+++ b/faq/support/64-bit.mdwn
@@ -0,0 +1,16 @@
+[[!meta copyright="Copyright © 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]]."]]"""]]
+
+[[!meta title="Is there a 64-bit version?"]]
+
+There are currently no plan for 64-bit userland, but there are plans for 64-bit
+kernelland with 32-bit userland, which will notably permit to efficiently make
+use of more than 2 GiB memory and provide 4 GiB userland addressing space.
+Work on this is currently in branches for GNU Mach.
diff --git a/faq/support/binary_compatibility.mdwn b/faq/support/binary_compatibility.mdwn
new file mode 100644
index 00000000..e9dfcdb8
--- /dev/null
+++ b/faq/support/binary_compatibility.mdwn
@@ -0,0 +1,33 @@
+[[!meta copyright="Copyright © 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_documentation]]
+
+IRC, freenode, #hurd, 2012-01-13:
+
+    <veganman> sothere's absolutelyno way,evenslowly to run i386 linuxcode
+      under hurd/i386? Ihave a small app, commercial, which I have to get
+      running there
+    <veganman> no source
+    <braunr> no way
+    <braunr> you'd need to create a userspace linux server catching linux
+      system calls and calling hurd specific stuff to implement them
+    <braunr> it doesn't exist, it may be hard to implement
+    <braunr> some cases will definitely be hard to implement
+    <veganman> so, no magic linux lxemu on windows?
+    <veganman> or linuxemu on plan9
+    <pinotree> nope
+    <veganman> I remember somethingsilly, sonmone hadcompiled linux asauser
+      applicationon plan9 and inserted his own binaries as
+      acodeobject,toberunon plan9, for useon ibm hpc hatrdware
+    <veganman> it was ron minich
+    <veganman> 5e.iwp9.org/slides/linuxemu.pdf
+    <veganman> I think that was it
+    <veganman> google for linux & cnk for additional clues
diff --git a/faq/support/fuse_support.mdwn b/faq/support/fuse_support.mdwn
new file mode 100644
index 00000000..33e877ce
--- /dev/null
+++ b/faq/support/fuse_support.mdwn
@@ -0,0 +1,13 @@
+[[!meta copyright="Copyright © 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]]."]]"""]]
+
+[[!meta title="Does Hurd support FUSE?"]]
+
+There is a start of work on implementing a [[FUSE|hurd/libfuse]] library on Hurd; its support is not updated to the latest version, but at least some fuse filesystems do work already.
diff --git a/faq/support/network_transparency.mdwn b/faq/support/network_transparency.mdwn
new file mode 100644
index 00000000..aefaf500
--- /dev/null
+++ b/faq/support/network_transparency.mdwn
@@ -0,0 +1,22 @@
+[[!meta copyright="Copyright © 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_documentation]]
+
+IRC, freenode, #hurd, 2012-01-21:
+
+    <chromaticwt> is it possible to transfer servers running on one microkernel
+      on one machine, to another microkernel running on a different machine?
+    <chromaticwt> two machines will be running the complete os
+    <antrik> well, if the code for network-transparent IPC still existed, it
+      might be possible to move a task to another machine, while keeping the
+      port associations with the original system...
+    <antrik> if you mean actually moving it to another system, that's pretty
+      much impossible in any system that has stateful interfaces
diff --git a/faq/support/posix_compatibility.mdwn b/faq/support/posix_compatibility.mdwn
new file mode 100644
index 00000000..4490b7cb
--- /dev/null
+++ b/faq/support/posix_compatibility.mdwn
@@ -0,0 +1,32 @@
+[[!meta copyright="Copyright © 2010, 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]]."]]"""]]
+
+[[!meta title="POSIX compatibility"]]
+
+Is it favorable of rather a hindrance to be compatible to POSIX and similar
+standards?
+
+A lot of things in POSIX et al. are designed for [[UNIX]]-like systems with
+traditional monolithic [[kernel]]s.
+
+Thus, a [[microkernel]]-based system, as ours is, has to employ a bunch of
+detours, for example to implement the [[`fork` system call|glibc/fork]].
+
+On the other hand, (mostly) complying to these standards, made a really big
+body of software *just work* without any (or just trivial) [[hurd/porting]].
+Especially so for command-line programs, and libraries.
+
+But: a large part of today's user programs are not written according to POSIX
+et al. low-level interfaces, but against GNOME, GTK+2, and other high-level
+frameworks and libraries.  It may be a valid option to enrich these instead of
+striving for total POSIX compliance -- and the high-level programs (that is,
+their users) may not even notice this, but we would avoid a lot of overhead
+that comes with wrapping the [[Hurd interfaces|hurd/interface]] to be POSIX
+compliant.
diff --git a/faq/support/posix_compatibility/discussion.mdwn b/faq/support/posix_compatibility/discussion.mdwn
new file mode 100644
index 00000000..0d722c9e
--- /dev/null
+++ b/faq/support/posix_compatibility/discussion.mdwn
@@ -0,0 +1,25 @@
+[[!meta copyright="Copyright © 2010, 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_documentation]]
+
+\#hurd IRC channel on Freenode, 2010-12-21:
+
+    <antrik> tschwinge: the writeup ignores the fact that POSIX compatibility
+      is not only for applications, but also for users familiar with the UNIX
+      environment
+    <antrik> also, I still don't buy the fact that most software is not written
+      for POSIX. even if assuming that GNOME programs don't use POSIX (which is
+      only half true), there is a lot of other software in a system that is
+      just as important, though less visible
+    <antrik> (server software, startup system, device management, automation,
+      ...)
+    <antrik> tschwinge: BTW, I meant to (and partially did) write a blog
+      article on this topic -- but I didn't get around to finish it...
diff --git a/faq/support/ram_limit.mdwn b/faq/support/ram_limit.mdwn
new file mode 100644
index 00000000..0fa27c2e
--- /dev/null
+++ b/faq/support/ram_limit.mdwn
@@ -0,0 +1,22 @@
+[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]]
+
+[[!meta title="830 MiB RAM Limit"]]
+
+Just like any 32-bit OS without bad tricks, GNU Mach can not cope well with lots
+of memory.  Latest versions of the Debian `gnumach` package will limit themselves
+to around 1.7 GiB of memory. If you want more, you can twiddle the `VM_MAX_ADDRESS`
+limit between kernelland and userland in `i386/include/mach/i386/vm_param.h`.
+
+If you have an older version, or still experience problems with `vmstat` (see
+above) reported much less memory than you have, the best is to limit the memory
+it can see via GRUB's `upppermem` feature.  Add `uppermem 786432` to GRUB's Hurd
+entry in `menu.lst`.
diff --git a/faq/support/sata_disk_drives.mdwn b/faq/support/sata_disk_drives.mdwn
new file mode 100644
index 00000000..69470f10
--- /dev/null
+++ b/faq/support/sata_disk_drives.mdwn
@@ -0,0 +1,17 @@
+[[!meta copyright="Copyright © 2008, 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]]."]]"""]]
+
+[[!meta title="Are SATA disk drives supported?"]]
+
+GNU Mach does not support SATA disk drives (`/dev/sda` etc. in GNU/Linux)
+natively, so using `device:sd0s1` will not work, as sd* devices are for SCSI
+drives only.
+The only way to get those drives to work is to put them into compatibility mode
+in the BIOS, if such an option exists.  GNU Mach will then recognize them as hda etc.
diff --git a/faq/support/sharing_the_user_space.mdwn b/faq/support/sharing_the_user_space.mdwn
new file mode 100644
index 00000000..2c31c22b
--- /dev/null
+++ b/faq/support/sharing_the_user_space.mdwn
@@ -0,0 +1,24 @@
+[[!meta copyright="Copyright © 2010, 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]]."]]"""]]
+
+[[!meta title="Sharing the userspace between GNU Hurd and the Linux kernel"]]
+
+Given that both Linux and GNU Hurd are using the [[ELF]] binary
+format, it is in theory possible to have a system installation where you can
+dual-boot using either the [[Linux]] kernel, or the GNU Hurd, so that
+everything but the kernel is shared.
+For this, all programs need to agree to rely on
+only one abstraction layer, for example the standard C library ([[glibc]]).
+(Additionally, for example for [[system call]]s that are not covered by glibc
+calls, you'd need to be able to reliably trap and emulate these.)  However,
+Linux' and the GNU Hurd's [[ABI]]'s have sufficiently diverged, so that this is
+not easy to do.  That's why you can't currently install a system in this way,
+but you need a separate installation of the userspace suited for the Linux
+kernel, or the GNU Hurd.
diff --git a/faq/support/smp.mdwn b/faq/support/smp.mdwn
new file mode 100644
index 00000000..e95edcd2
--- /dev/null
+++ b/faq/support/smp.mdwn
@@ -0,0 +1,28 @@
+[[!meta copyright="Copyright © 2009, 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]]."]]"""]]
+
+[[!meta title="Does GNU/Hurd support SMP/Multicore?"]]
+
+The Hurd servers themselves are multithreaded, so they should be able to take benefit of the parallelism brought by SMP/Multicore boxes. This has however never been tested yet because of the following.
+
+[[microkernel/Mach]] used to be running on SMP boxes like the [[!wikipedia
+Intel_iPSC/860]], so principally has the required infrastructure.  It has
+however not yet been enhanced to support nowadays' SMP standards like ACPI,
+etc.  Also, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue
+code likely isn't SMP-safe.  As this glue code layer is not used in the
+[[microkernel/mach/gnumach/ports/Xen]] port of GNU Mach, the plan is to try it
+in this enviroment first.
+
+[[!tag open_issue_gnumach open_issue_xen]]
+
+That is why for now GNU/Hurd will only use one logical processor (i.e. one core or one thread, depending on the socket type).
+
+Once this issue is solved, there are follow-up issues about
+[[open_issues/multiprocessing]] and [[open_issues/multithreading]].
diff --git a/faq/support/system_port.mdwn b/faq/support/system_port.mdwn
new file mode 100644
index 00000000..c831c36f
--- /dev/null
+++ b/faq/support/system_port.mdwn
@@ -0,0 +1,47 @@
+[[!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]]."]]"""]]
+
+[[!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.