diff options
author | Thomas Schwinge <thomas@codesourcery.com> | 2013-03-19 18:47:23 +0100 |
---|---|---|
committer | Thomas Schwinge <thomas@codesourcery.com> | 2013-03-19 18:47:23 +0100 |
commit | d166bfaaa3ddf8b83b5cc6bde62f8872e6a80c82 (patch) | |
tree | 4d8a8904c2c49122c37895ed4573a5fcbd19ed4f /faq/support | |
parent | 64f867bbc45d265009a1bad590bc1d4d9ea91d6e (diff) | |
parent | ce8c2531cdb7ee05784437da4c38459e5d3897d6 (diff) | |
download | web-d166bfaaa3ddf8b83b5cc6bde62f8872e6a80c82.tar.gz web-d166bfaaa3ddf8b83b5cc6bde62f8872e6a80c82.tar.bz2 web-d166bfaaa3ddf8b83b5cc6bde62f8872e6a80c82.zip |
Merge remote-tracking branch 'savannah/master'
As part of the merge, fix some typos, add copyright and licensing headers, and
a few more minor changes.
Diffstat (limited to 'faq/support')
-rw-r--r-- | faq/support/0-drivers.mdwn | 18 | ||||
-rw-r--r-- | faq/support/0-software.mdwn | 16 | ||||
-rw-r--r-- | faq/support/2_gib_partition_limit.mdwn | 16 | ||||
-rw-r--r-- | faq/support/64-bit.mdwn | 16 | ||||
-rw-r--r-- | faq/support/binary_compatibility.mdwn | 33 | ||||
-rw-r--r-- | faq/support/fuse_support.mdwn | 13 | ||||
-rw-r--r-- | faq/support/network_transparency.mdwn | 22 | ||||
-rw-r--r-- | faq/support/posix_compatibility.mdwn | 32 | ||||
-rw-r--r-- | faq/support/posix_compatibility/discussion.mdwn | 25 | ||||
-rw-r--r-- | faq/support/ram_limit.mdwn | 22 | ||||
-rw-r--r-- | faq/support/sata_disk_drives.mdwn | 17 | ||||
-rw-r--r-- | faq/support/sharing_the_user_space.mdwn | 24 | ||||
-rw-r--r-- | faq/support/smp.mdwn | 28 | ||||
-rw-r--r-- | faq/support/system_port.mdwn | 47 |
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 && cd <package\_dir> && 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. |