diff options
33 files changed, 226 insertions, 287 deletions
diff --git a/challenges.mdwn b/challenges.mdwn index 4c8e00f0..6a767aa7 100644 --- a/challenges.mdwn +++ b/challenges.mdwn @@ -19,12 +19,12 @@ successful true multi-server [[microkernel]] system for general-purpose desktop use yet. This is still an ongoing research effort. Also the Hurd is not the only multiserver operating system. Other examples include: [[Genode OS|https://genode.org/]] (FOSS), [[MINIX 3|https://www.minix3.org/]] (FOSS), -[[HELON OS|http://www.helenos.org/]] (FOSS), and [[QNX|https://blackberry.qnx.com/en]] -(proprietary). +[[HELON OS|http://www.helenos.org/]] (FOSS), [[Redox OS|https://www.redox-os.org/]], +and [[QNX|https://blackberry.qnx.com/en]] (proprietary). -Likewise, resource scheduling in distributed operating system kernels is a -research topic. For example, read more about it on the relevant [[Open Issues -page|open_issues/multiprocessing]]. Also, the [[microkernel/Viengoos]] -research kernel project strives to explore these. +Likewise, [[resource scheduling|open_issues/multiprocessing]] in distributed operating system kernels is a +research topic. The GNU/Hurd also has +[[open_issues/resource_management_problems]]. The [[microkernel/Viengoos]] +research kernel project strives to fix these issues, but its development has ended. TODO: more to come. [[!tag open_issue_documentation]] diff --git a/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn b/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn index 35e55518..b2fa5585 100644 --- a/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn +++ b/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn @@ -15,13 +15,22 @@ The filesystem implements stuff like Gnome VFS (gvfs) and KDE **network transpar One practical advantage of this is that the following works: - settrans -a ftp\: /hurd/hostmux /hurd/ftpfs / - dpkg -i ftp://ftp.gnu.org/path/to/*.deb + $ settrans -a ftp\: /hurd/hostmux /hurd/ftpfs / + $ dpkg -i ftp://ftp.gnu.org/path/to/*.deb This installs all deb-packages in the folder `path/to` on the FTP server. The shell sees normal directories (beginning with the directory “ftp:”), so shell expressions just work. You could even define a Gentoo mirror translator (`settrans mirror\: /hurd/gentoo-mirror`), so every program could just access mirror://gentoo/portage-2.2.0_alpha31.tar.bz2 and get the data from a mirror automatically: `wget mirror://gentoo/portage-2.2.0_alpha31.tar.bz2` +How about mounting a remote ISO file? Now that we can access ftp.gnu.org transparently, +this is trivial! + + $ settrans -c mnt /hurd/iso9660fs $PWD/ftp://ftp.gnu.org/old-gnu/gnu-f2/hurd-F2-main.iso + $ ls mnt/ + +It is interesting to note that since the ISO9660 format is indexed, ftpfs does not have to +download the whole ISO file, it merely fetches what iso9660fs requests. + Or you could add a unionmount translator to root which makes writes happen at another place. **Every user is able to make a readonly system readwrite** by just specifying where the writes should go. But the writes **only affect his view of the filesystem**. Starting a network process is done by a translator, too: The first time something accesses the network card, the network translator starts up and actually provides the device. This replaces most **initscripts in the Hurd: Just add a translator to a node**, and the service will persist over restarts. diff --git a/contributing.mdwn b/contributing.mdwn index 7f4f3554..127554a4 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -160,7 +160,6 @@ packages](http://people.debian.org/~sthibault/hurd-i386/failed_packages.txt). This is the list of tasks that we *want* to address soon, starting with the most pressing: -* Add amd64 support to gdb, see [Flavio patch pending commit](https://sourceware.org/pipermail/gdb-patches/2024-February/206895.html) * Fix shell output pipe replacement issue on amd64, see [discussion](https://lists.gnu.org/archive/html/bug-hurd/2023-10/msg00062.html). - This means adding an `i386x_float_state` and `i386_XFLOAT_STATE` thread status, that glibc would be able to use along `i386_REGS_SEGS_STATE` and `i386_FLOAT_STATE` in `_hurd_setup_sighandler` and `sigtreturn.c`. The structure would contain the `fp_save_kind`. That'll actually be needed both on `i386` and `x86_64` actually, to fix SSE use against signals in general. @@ -172,7 +171,8 @@ This is the list of tasks that we *want* to address soon, starting with the most * Port `dhcpcd`, see [call for help](https://lists.debian.org/debian-hurd/2023/11/msg00030.html) * Make sure that lwip supports configuration by DHCP. * Extensively test (e.g. running testsuites of glibc, perl, curl, rust-mio) and fix the lwip-based TCP/IP stack, to be sure we don't get regressions by switching to it. -* Fix swapping with `rumpdisk`. +* Fix swapping with `rumpdisk` + * Apparently some wiring cases is not effective, we are seeing pageout of rumpdisk memory. * Fix the [GPLv2 vs GPLv3 licence incompatibility between ext2fs and libparted](https://bugs.debian.org/838244): * For /hurd/ext2fs, use a different libstore that does not include the parted module. * For /hurd/ext2fs.static in the bootstrap chain (e.g. to access wd0s1), add a storeio translator before it, and have ext2fs open it, use `file_get_storage_info` and access the underlying device. That wouldn't need any code modification if we were using an initial ramfs exposing that storeio on /dev/wd0s1. @@ -187,13 +187,12 @@ This is the list of tasks that we *want* to address soon, starting with the most * Rewrite `pthread_cond_*`, `pthread_rwlock_*`, `pthread_barrier_*` to use `gsync`, like `pthread_mutex_*` do (also see the nptl implementations, possibly just share with them). * Improve rumpdisk's asynchronism, see end of `hurd/rumpdisk/block-rump.c`. * Check performance of `rumpdisk` against the in-`gnumach` drivers. -* Make `ext2fs` use xattr by default to store translators (see `use_xattr_translator_records`) after making sure the upgrade path works fine. * Finish glib's file monitoring (see [merge request draft](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3626) and [Debian bug](https://bugs.debian.org/1008208)) * Extend `ext2fs` to support 64bit time. * Fix the `git` testsuite (just a few tests failing, used to pass). -* Fix the `curl` testsuite (just a few tests failing). * Fix the `subversion` testsuite (just a few tests failing). * Fix the `vim` testsuite (just a few tests failing, used to pass). +* Fix the `cmake` testsuite (just a few tests failing in latest version 4.0.0). * Fix building `mesa`. * Fix building `wayland`. * Port `python-procps`. diff --git a/extensibility.mdwn b/extensibility.mdwn index ef89d5f2..bb1e0bee 100644 --- a/extensibility.mdwn +++ b/extensibility.mdwn @@ -17,5 +17,20 @@ no way to hook into the virtual file system. This has motivated the introductio of separate, parallel interfaces by both the GNOME and KDE projects to provide users a more integrated view of their objects. +The Hurd introduces the concept of [[translators|hurd/translator]] to let users +hook into the virtual filesystem. We have translators that let ordinary users +create their own [[ext2 filesystem|hurd/translator/ext2fs]], +[[ftp filesystem|hurd/translator/ftpfs]], iso filesystem, +[[http filesystem|hurd/translator/httpfs]], etc. You can get started using +the existing translators by reading the [[how to|hurd/translator/examples]] page. + +The Hurd's extensibility is not just limited to the VFS. It is possible for +users to have their own [[TCP/IP|hurd/translator/pfinet]] +[[stack|hurd/translator/lwip]] using the [[hurd/translator/remap]] +translator. Users can create their own +[[personal firewall|https://darnassus.sceen.net/~hurd-web/hurd/translator/eth-filter/]], +run a personal [[hurd/translator/auth]] server, or isolate untrusted applications inside +a [[hurd/subhurd]]. The possibilities are endless! + # External * The Wikipedia article on [[!wikipedia extensibility]] diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn index a41d215d..d3d6d046 100644 --- a/faq/64-bit.mdwn +++ b/faq/64-bit.mdwn @@ -13,23 +13,17 @@ License|/fdl]]."]]"""]] [[!meta title="Is there a 64-bit version?"]] -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 +64-bit kernelland is supported with 32-bit userland, which notably +permits to efficiently make use of more than 2 GiB memory and provide 4 GiB userland addressing space. -A 64-bit GNU/Hurd is also coming soon, -progress is tracked on [[open_issues/64-bit_port]]! -Hurd developers ported GNUMach to -64-bit some time ago. Then they started making significant progress -on the x86_64 userland port in Feb 2023. As of September 2024, the -Debian hurd-amd64 port works just like the hurd-i386, except for -missing packages and more -[[bugs|https://lists.gnu.org/archive/html/bug-hurd/2024-07/msg00058.html]], -namely swapping issues with rumpdisk and deadlocking issues with -libdiskfs/ext2fs. We are currently building -64-bit packages. We plan on supporting both a 32-bit and 64-bit Debian -GNU/Hurd, only not both at the same time. However, there is no plan to fix the -year 2038 concern on a 32-bit system. +A 64-bit GNU/Hurd is also available, progress is tracked on [[open_issues/64-bit_port]]! +As of April 2025, the Debian hurd-amd64 port works just like the hurd-i386, except for +some bugs, namely swapping issues with rumpdisk and dumping core files. + +We plan on supporting both a +32-bit and 64-bit Debian GNU/Hurd, only not both at the same time. +However, there is no plan to fix the year 2038 concern on a 32-bit system. That being said, you can always run a 32-bit version on a 64-bit machine, it just works, processes are just limited to a couple GiB available memory. diff --git a/faq/context_switch.mdwn b/faq/context_switch.mdwn index 2d090c4c..55d20429 100644 --- a/faq/context_switch.mdwn +++ b/faq/context_switch.mdwn @@ -17,7 +17,13 @@ It is not, there is no real reason why it would be particularly slow, it is just about switching virtual addresses and registers, which all OS have to perform anyway. -A quick-and-dirty benchmark: +A quick-and-dirty benchmark. + +You can build this file with: + + gcc -pthread -rt -o context-switch context-switch.c + +In `context-switch.c` write: #include <fcntl.h> #include <semaphore.h> diff --git a/faq/debugging_translators.mdwn b/faq/debugging_translators.mdwn index 1bd0deec..031b5778 100644 --- a/faq/debugging_translators.mdwn +++ b/faq/debugging_translators.mdwn @@ -11,12 +11,4 @@ License|/fdl]]."]]"""]] [[!tag faq/development]] -In order to [[debug|debugging]] translators and being able to step into glibc -during it, on Debian you need the `hurd-dbgsym` and `libc0.3-dbg` packages installed. -If you need to debug the initialization of the translator, start the translator -like - - $ settrans -Pa /foo /usr/bin/env LD_LIBRARY_PATH=/usr/lib/debug /hurd/foofs - -The `-P` option will make it -pause and you will be able to attach [[debugging/GDB]] to the process. +See [[/hurd/debugging/translator]]. diff --git a/faq/drivers.mdwn b/faq/drivers.mdwn index 923e3b38..16d60a9a 100644 --- a/faq/drivers.mdwn +++ b/faq/drivers.mdwn @@ -19,14 +19,18 @@ and you can use an [[SSD|hurd/rump/rumpdisk]]. If you have difficulty installing the Hurd, then try setting your harddrive mode to "legacy" in the BIOS. A cheaper option is the T43 (2GB max RAM). -Other working Thinkpads include the X200, T400, or T500 Thinkpads, +Other working Thinkpads include the X200, T400, +[[T410|https://logs.guix.gnu.org/hurd/2025-04-25.log#103752]] or T500 Thinkpads, which support internet connectivity via the ethernet port. You can use an [[SSD|hurd/rump/rumpdisk]] on these laptops, which support a maximum of 8GB of RAM. The Debian installer images from 2023 fail to boot these machines, but you can install the Hurd via [[Debian's -CrossInstall|hurd/running/debian/CrossInstall]]. Until we fix the -libdiskfs/ext2fs issues on the [[64 bit port|faq/64-bit]], we -recommend that you use the 32 bit version of the Hurd. +CrossInstall|hurd/running/debian/CrossInstall]] or +[[mmdebstrap|https://lists.debian.org/debian-hurd/2024/12/msg00003.html]]. + +_While the [[64 bit port|faq/64-bit]] is about as stable as the 32-bit +port, the rumpdisk support needed for it is still relatively experimental. +For this reason we recommend casual Hurd users to use the 32 bit port._ Other hardware that is known to work includes the [[Dell Inspiron 1750|https://logs.guix.gnu.org/hurd/2024-09-28.log]] on i386 diff --git a/faq/foo_max.mdwn b/faq/foo_max.mdwn index 5f736680..ccd09904 100644 --- a/faq/foo_max.mdwn +++ b/faq/foo_max.mdwn @@ -18,7 +18,12 @@ For porting guidelines, see [[hurd/porting/guidelines#PATH_MAX_tt_MAX_PATH_tt_MA # Is it really standard not to define them? -These macros are indeed optional in Posix, so not defining them remains standard-compliant. +These macros are indeed optional in Posix, so not defining them remains +standard-compliant. Quoting the standard: + + A definition of one of the symbolic constants in the following list shall be + omitted from <limits.h> on specific implementations where the corresponding + value is equal to or greater than the stated minimum, but is unspecified. Their definition was actually not completely clear, Posix 1990 was ambiguous about it including `\0` or not, it was made clear later on that it does include @@ -30,13 +35,14 @@ even depend on its revision, so to be rather queried at runtime with `pathconf`. # But it's really convenient! Isn't allocating dynamically much more complex? `FOO_MAX` constants are most often used as “reasonable size to allocate a -path”. On Linux it is typically 4096, which is not that reasonable (a whole +path”. On Linux `PATH_MAX` is typically 4096, which is not that reasonable (a whole memory page, thus a TLB lookup) when manipulating a lot of paths. Allocating dynamically would use much less memory. Most often interfaces can be made to properly allocate dynamically. Notably, -since Posix 2008 `realpath(path, NULL)` and `getcwd(NULL, 0)` allocate the path -dynamically. +since Posix 2008 `realpath(path, NULL)` allocates the path dynamically. +Posix 2008 does not say that `getcwd(NULL, 0)` allocates the path dynamically, +but BSD, Linux, and even windows do. In general, using `FOO_MAX` in source code (with a large value) leads to code that is not actually checking against overflows. `PATH_MAX` being 4096 is diff --git a/hurd/debugging/translator/gdb.mdwn b/hurd/debugging/translator/gdb.mdwn index 82a50736..fdf6adff 100644 --- a/hurd/debugging/translator/gdb.mdwn +++ b/hurd/debugging/translator/gdb.mdwn @@ -12,6 +12,8 @@ Say you want to try running file system server ([[`ext2fs`|translator/ext2fs]], [[`jfs`|translator/jfs]], ...) against a modified version of [[`libpager`|libpager]] and debug the latter one using [[debugging/GDB]]. +On Debian you need the `hurd-dbgsym` and `libc0.3-dbg` packages installed. + Set the [[hurd/translator]] like this: $ settrans -fgap ↩ @@ -51,3 +53,11 @@ course): [...] Voilà. + +If you need to debug the initialization of the translator, start the translator +like + + $ settrans -Pa /foo /hurd/foofs + +The `-P` option will make it +pause and you will be able to attach [[debugging/GDB]] to the process. diff --git a/hurd/glibc.mdwn b/hurd/glibc.mdwn index 8e330aef..736cc099 100644 --- a/hurd/glibc.mdwn +++ b/hurd/glibc.mdwn @@ -49,6 +49,10 @@ One can build libc this way: $ make $ make check -k +One can run tests individually with: + + $ make test t=wcsmbs/test-wcsnlen + One can run tests with the new libc by hand: $ ./testrun.sh ~/test diff --git a/hurd/rump/rumpusbdisk.mdwn b/hurd/rump/rumpusbdisk.mdwn index 26e1a101..8463e670 100644 --- a/hurd/rump/rumpusbdisk.mdwn +++ b/hurd/rump/rumpusbdisk.mdwn @@ -14,7 +14,7 @@ License|/fdl]]."]]"""]] # RumpUSBDisk With RumpUSBDisk, the Hurd can use a usb to SATA dongle to access a -SATA device. The StarTech offers a good quality dongle that works +SATA device. StarTech offers a good quality dongle that works well. The Hurd could then read/write data from a SATA device with an fatfs or ext2 filesystem. Damien Zammit implemented [[rumpusbdisk already|https://lists.gnu.org/archive/html/bug-hurd/2023-07/msg00025.html]]. diff --git a/hurd/running/debian/CrossInstall.mdwn b/hurd/running/debian/CrossInstall.mdwn index 26cd77af..0f56a3e7 100644 --- a/hurd/running/debian/CrossInstall.mdwn +++ b/hurd/running/debian/CrossInstall.mdwn @@ -56,13 +56,6 @@ Ah, reboot and select "GNU (kernel GNUmach 1.3)" from the Grub menu. At the prom # export TERM=mach # ./native-install -When done the native install requests that you reboot once again and rerun native-install. - - # reboot - ... - # export TERM=mach - # ./native-install - Done, continue setting up your system. ---- diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index 9984ac33..8409bc8c 100644 --- a/hurd/running/debian/qemu_image.mdwn +++ b/hurd/running/debian/qemu_image.mdwn @@ -42,7 +42,7 @@ Optionally you may use `--curses` to keep your keyboard layout. If need be modpr Note that if you do not have a command named `kvm`, you can try something across the lines of: - $ qemu-system-i386 --enable-kvm -drive cche=writeback,file=$(echo debian-hurd-*.img) -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 + $ qemu-system-i386 --enable-kvm -drive cache=writeback,file=$(echo debian-hurd-*.img) -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000 Or, if your machine does not allow for KVM acceleration, omit `--enable-kvm` from the command. diff --git a/hurd/running/gnu.mdwn b/hurd/running/gnu.mdwn index 964e7e8e..b45841df 100644 --- a/hurd/running/gnu.mdwn +++ b/hurd/running/gnu.mdwn @@ -2,31 +2,32 @@ # <a name="The_GNU_Operating_System"> </a> The GNU Operating System -The GNU Operating System, Commonly referred to as simply "The GNU System", is a +The GNU Operating System, commonly referred to as simply "The GNU System", is a complete [[Unix]]-like operating system composed entirely of [free software](http://www.gnu.org/philosophy/free-sw.html). The creation of the GNU System is one of the goals of the [GNU Project](http://www.gnu.org/), which was [launched in 1983](http://www.gnu.org/gnu/initial-announcement.html) by -[Richard Stallman](http://www.stallman.org/). It has many ambitious goals that -the GNU/Hurd intends to address. - -These goals include increased security through the [[principle of least -privilege|https://en.wikipedia.org/wiki/Principle%5Fof%5Fleast%5Fprivilege]], an -[[extensible system|extensibility]], conformation to open operating standards -including [[POSIX|https://en.wikipedia.org/wiki/POSIX]], modularity, and -respecting user freedom. Many of these goals are things that the GNU/Hurd can -resolve, however the GNU/Hurd is not the most stable operating system yet. +[Richard Stallman](http://www.stallman.org/). The GNU/Hurd intends to +increase security through the [[principle of least +privilege|https://en.wikipedia.org/wiki/Principle%5Fof%5Fleast%5Fprivilege]], provide an +[[extensible system|extensibility]], conform to open operating standards +including [[POSIX|https://en.wikipedia.org/wiki/POSIX]], contain a modular code-base, and +[[respect user freedom|https://www.gnu.org/philosophy/free-sw.html]]. +Many of these goals are things that the GNU/Hurd can +resolve, however the GNU/Hurd is not yet the most stable operating system. If you are looking for a production ready GNU system, then [[hurd/running/Debian]] GNU/Hurd may -not be the best choice for you. Debian GNU/Hurd currently lacks 64-bit support, -many device drivers, sound support, SMP, and a few other essential bits that -provide a flexible operating system. +not be the best choice for you. Debian GNU/Hurd currently lacks many device drivers, sound +support, and a few other essential bits that provide a flexible operating system. +It also has some tricky [[problems|challenges]] to solve. However, [[gnu.org|https://www.gnu.org/distros/free-distros.html]] maintains a list of freedom respecting and production ready GNU/Linux systems. One of the -most promising of these is [[GuixSD|https://www.gnu.org/software/guix/]], which +most promising of these is [[Guix System|https://www.gnu.org/software/guix/]], which is the GNU Guix System Distribution, which eventually plans to support the GNU -Hurd as the kernel! +Hurd as the kernel! You can even use a +[[childhurd|https://guix.gnu.org/manual/devel/en/html_node/Virtualization-Services.html#The-Hurd-in-a-Virtual-Machine]] +on Guix System! ## Resources diff --git a/hurd/status.mdwn b/hurd/status.mdwn index bc04d78d..28919995 100644 --- a/hurd/status.mdwn +++ b/hurd/status.mdwn @@ -34,6 +34,8 @@ drivers, and experimental support for SATA devices was added in May 2013. Robert Millan worked on a port of the Rump kernel, which allowed to run a sound driver in userland. This work now needs to be extended. Support for character devices and other hardware (USB, multicore) is mostly missing. +Damien Zammit added [[RumpDisk|hurd/rump/rumpdisk]], which lets the Hurd +boot and use SSDs with a minimal NetBSD kernel running in userspace. Although the [[POSIX interface|faq/posix_compatibility]] is provided, some additional interfaces @@ -56,14 +58,28 @@ official Debian release), in April 2015 the [[Debian GNU/Hurd|hurd/running/debian]] team released [[Debian GNU/Hurd 2015|news/2015-04-29-debian_gnu_hurd_2015]]. Similarly, along Debian "stretch", in June 2017 [[Debian GNU/Hurd 2017|news/2017-06-18-debian_gnu_hurd_2017]] was released. +The latest release is from +[[2023|https://darnassus.sceen.net/~hurd-web/news/2023-06-11-debian_gnu_hurd_2023/]]. + +With [[Guix System|hurd/running/guix]] one can trivially run a childhurd or a +hurd vm running atop GNU/Linux. The adventurous can run it on +[[real iron|https://guix.gnu.org/blog/2024/hurd-on-thinkpad/]]. [[hurd/running/Arch_Hurd]] offers *LiveCDs* for testing and installation. [[hurd/running/Nix]] provides QEMU images. - ## Usability Reports +### Joshua Branson, 2025-04-30 + +I've had my T43 Thinkpad with 1.5 GB of RAM running Debian GNU/Hurd +for about a year now. I use a combination of the i3 window +manager, emacs, git, the netsurf web browser, and a terminal to edit +this wiki. The Hurd is fairly stable, but it tends to lock up on me +about once a month. While I am fairly certain that I have had some +filesystem corruption, I have not noticed any lost files yet. + ### Svante Signell, 2013-05-21 I have been running GNU/Hurd for some years now, with VMs, mainly in the diff --git a/hurd/translator/remap.mdwn b/hurd/translator/remap.mdwn index a0544c7c..06e3c8c5 100644 --- a/hurd/translator/remap.mdwn +++ b/hurd/translator/remap.mdwn @@ -31,9 +31,12 @@ On Debian, `/bin/sh` points to `dash`. Maybe you would rather it point to `bash`. $ ls -lha /bin/sh - lrwxr-xr-x 1 root root 4 Jun 5 04:08 /bin/sh -> dash + lrwxr-xr-x 1 root root 4 Jun 5 04:08 /bin/sh -> dash $ remap /bin/sh /bin/bash -- ls -lha /bin/sh - -rwxr-xr-x 1 root root 1,2M 20 oct. 12:53 /bin/sh + -rwxr-xr-x 1 root root 1,2M 20 oct. 12:53 /bin/sh + /bin/settrans: fsys_goaway: (ipc/mig) server died + +(the warning is expected, it just tells that the exected command has finished) ## remapping python3 diff --git a/hurd/what_is_the_gnu_hurd.mdwn b/hurd/what_is_the_gnu_hurd.mdwn index 09c26ee7..0ccead52 100644 --- a/hurd/what_is_the_gnu_hurd.mdwn +++ b/hurd/what_is_the_gnu_hurd.mdwn @@ -12,6 +12,13 @@ License|/fdl]]."]]"""]] [[!meta title="What Is the GNU Hurd?"]] The Hurd is the GNU project's replacement for the [[UNIX]] system's [[kernel]]. +There are several +[[free software operating systems|https://www.gnu.org/distros/free-distros.en.html]] +using the [[Linux kernel|https://en.wikipedia.org/wiki/Linux_kernel]]. The +Hurd is an alternate operating system that uses a different kernel. You can +read more about the status of the Hurd [[here|hurd/status]]. If you decide +to use the Hurd, then we would recommend +[[the Debian GNU/Hurd distribution|https://www.debian.org/ports/hurd/]]. The Hurd is firstly a collection of protocols formalizing how different components may interact. The protocols are designed to reduce the mutual @@ -23,7 +30,8 @@ access to its backing store and that the [[principal]] that started it own the file system node to which it connects. The Hurd is also a set of [[servers|translator]] that implement these -protocols. They include file systems, network protocols and authentication. +protocols. They include [[file systems|hurd/translator/ext2fs]], network +protocols and [[authentication|hurd/translator/auth]]. The servers run on top of the [[microkernel/Mach]] [[microkernel]] and use Mach's [[microkernel/mach/IPC]] mechanism to transfer information. @@ -39,8 +47,8 @@ programs and libraries to operate. Let's look at an example. Firefox invokes glibc's `send ()`, which in turn uses the pfinet (or lwip) TCP/IP stack, which talk to our device drivers (rump or netdde), -which finally talk to GNU Mach. Only GNU Mach runs in kernel space! -Everything else is userspace! +which can actually access the hardware without entering kernel space +(GNU Mach). That's a lot of power for userspace! The Hurd supplies the last major software component needed for a complete [[GNU_operating_system|running/gnu]] as originally conceived by Richard @@ -51,7 +59,10 @@ organization that is the home of the [GNU project](http://gnu.org/gnu/). The Hurd development effort is a somewhat separate project from the [[Debian_GNU/Hurd|hurd/running/debian]] port. +Want to know what the Hurd can do? Read the [[status|hurd/status]] page. Read about what the GNU Hurd is [[gramatically_speaking]]. Read about the [[origin_of_the_name]]. + +Want to read more [[Hurd documentation|hurd/documentation]]? diff --git a/microkernel/mach/external_pager_mechanism.mdwn b/microkernel/mach/external_pager_mechanism.mdwn index ccb72421..4bc863f1 100644 --- a/microkernel/mach/external_pager_mechanism.mdwn +++ b/microkernel/mach/external_pager_mechanism.mdwn @@ -39,10 +39,10 @@ is sent an [[exception]], which is normally further propagated as a segmentation fault. If there is an associated memory object, Mach checks whether the corresponding [[page]] is in core. If it is, it installs the page and resumes the task. Mach -then invokes the memory object with the `memory_object_request` +then invokes the memory object with the `memory_object_data_request` method and the page to read. The memory manager then fetches or creates the content as appropriate and supplies it to -Mach using the `memory_object_supply` method. +Mach using the `memory_object_data_supply` method. # Creating and Mapping a Memory Object @@ -120,7 +120,7 @@ mappings etc. (A) The client does a memory access and [[faults|page_fault]]. The kernel catches the fault and maps the address to the appropriate memory object. It -then invokes the `memory_object_request` method on the associated +then invokes the `memory_object_data_request` method on the associated capability. (In addition to the page to supply, it also supplies the control port so that the server can determine which kernel sent the message.) @@ -147,7 +147,7 @@ its own address space at the same time. (E) The storeio server transfers the page to the server. The page is still anonymous. -(F) The manager does a `memory_object_supply` transferring the page to +(F) The manager does a `memory_object_data_supply` transferring the page to the kernel. Only now is the page not considered to be anonymous but managed. @@ -174,8 +174,8 @@ if the server does not deallocate the page quickly enough, it cannot cause a denial of service: the kernel will just later double page it to swap (the default pager is part of the [[tcb]]). -(C) Mach then invokes `memory_object_return` <!-- doesn't exist --> method on the control -object. The server is expected to save the page free <!-- ? --> it in a timely +(C) Mach then invokes `memory_object_data_return` method on the control +object. The server is expected to save the page and free it in a timely fashion. The server is not required to send a response to the kernel. (D) The manager then transfers the data to the storeio server which diff --git a/microkernel/mach/gnumach/projects/mach_5.mdwn b/microkernel/mach/gnumach/projects/mach_5.mdwn index 7b59170b..d7355f4b 100644 --- a/microkernel/mach/gnumach/projects/mach_5.mdwn +++ b/microkernel/mach/gnumach/projects/mach_5.mdwn @@ -54,11 +54,11 @@ rewrite rights and pointers to out-of-band memory, it has to parse the message. As type information and values are interleaved, it has to iterate over the whole message. -Furthermore, there are two kinds of type descriptors, mach_msg_type_t -and mach_msg_type_long_t. The reason for this is that the amount of -data that can be described using mach_msg_type_t is just 131072 byte. -This is because msgt_size is an 8-bit value describing the size of one -element in bits, and msgt_number is an 12-bit value describing the +Furthermore, there are two kinds of type descriptors, `mach_msg_type_t` +and `mach_msg_type_long_t`. The reason for this is that the amount of +data that can be described using `mach_msg_type_t` is just 131072 byte. +This is because `msgt_size` is an 8-bit value describing the size of one +element in bits, and `msgt_number` is an 12-bit value describing the number of items. ### Required change to the message format diff --git a/news/2010.mdwn b/news/2010.mdwn index a1adc686..0e60451b 100644 --- a/news/2010.mdwn +++ b/news/2010.mdwn @@ -120,7 +120,7 @@ multi-server microkernel-based operating system, or if you are interested in contributing to Hurd development in general, please see <http://www.gnu.org/software/hurd/contributing.html>. Or just talk to us at <bug-hurd@gnu.org> or the `#hurd` IRC -channel on freenode. +channel on libera.chat. --- diff --git a/news/2013-09-27.mdwn b/news/2013-09-27.mdwn index 4c4e9b81..9f5f7d32 100644 --- a/news/2013-09-27.mdwn +++ b/news/2013-09-27.mdwn @@ -46,7 +46,7 @@ Bug reports should be sent to [[mailing_lists/bug-hurd]] or filed on <http://savannah.gnu.org/bugs/?group=hurd>. Requests for assistance should be sent to [[mailing_lists/help-hurd]] or filed on <http://savannah.gnu.org/support/?group=hurd>. You can also find us on -the Freenode IRC network in the [[#hurd|IRC]] channel. +the libera.chat IRC network in the [[#hurd|IRC]] channel. --- diff --git a/news/2015-04-10-releases.mdwn b/news/2015-04-10-releases.mdwn index 853eb81a..322c5000 100644 --- a/news/2015-04-10-releases.mdwn +++ b/news/2015-04-10-releases.mdwn @@ -36,7 +36,7 @@ Bug reports should be sent to [[mailing_lists/bug-hurd]] or filed on <http://savannah.gnu.org/bugs/?group=hurd>. Requests for assistance should be sent to [[mailing_lists/help-hurd]] or filed on <http://savannah.gnu.org/support/?group=hurd>. You can also find us on -the Freenode IRC network in the [[#hurd|IRC]] channel. +the libera.chat IRC network in the [[#hurd|IRC]] channel. --- diff --git a/news/2015-10-31-releases.mdwn b/news/2015-10-31-releases.mdwn index b721b1fd..7721b762 100644 --- a/news/2015-10-31-releases.mdwn +++ b/news/2015-10-31-releases.mdwn @@ -164,6 +164,6 @@ Bug reports should be sent to [[mailing_lists/bug-hurd]] or filed on <http://savannah.gnu.org/bugs/?group=hurd>. Requests for assistance should be sent to [[mailing_lists/help-hurd]] or filed on <http://savannah.gnu.org/support/?group=hurd>. You can also find us on -the Freenode IRC network in the [[#hurd|IRC]] channel. +the libera.chat IRC network in the [[#hurd|IRC]] channel. """]] diff --git a/news/2016-05-18-releases.mdwn b/news/2016-05-18-releases.mdwn index 33702f8c..f73b222f 100644 --- a/news/2016-05-18-releases.mdwn +++ b/news/2016-05-18-releases.mdwn @@ -174,6 +174,6 @@ Bug reports should be sent to [[mailing_lists/bug-hurd]] or filed on <http://savannah.gnu.org/bugs/?group=hurd>. Requests for assistance should be sent to [[mailing_lists/help-hurd]] or filed on <http://savannah.gnu.org/support/?group=hurd>. You can also find us on -the Freenode IRC network in the [[#hurd|IRC]] channel. +the libera.chat IRC network in the [[#hurd|IRC]] channel. """]] diff --git a/news/2016-12-18-releases.mdwn b/news/2016-12-18-releases.mdwn index 6d4f9e26..f6213488 100644 --- a/news/2016-12-18-releases.mdwn +++ b/news/2016-12-18-releases.mdwn @@ -165,6 +165,6 @@ Bug reports should be sent to [[mailing_lists/bug-hurd]] or filed on <http://savannah.gnu.org/bugs/?group=hurd>. Requests for assistance should be sent to [[mailing_lists/help-hurd]] or filed on <http://savannah.gnu.org/support/?group=hurd>. You can also find us on -the Freenode IRC network in the [[#hurd|IRC]] channel. +the libera.chat IRC network in the [[#hurd|IRC]] channel. """]] diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn index b85d95de..01a2aad5 100644 --- a/open_issues/64-bit_port.mdwn +++ b/open_issues/64-bit_port.mdwn @@ -13,171 +13,25 @@ License|/fdl]]."]]"""]] [[!inline pages="title(Is there a 64-bit version?)" feeds="no" raw="yes"]] -**What is left for initial support (32-on-64) is** - - * Fixing bugs :) - **For pure 64bit support, we need to** * bootstrap a distribution. Debian is done. Alpine-Hurd is mostly bootstrapped. Reach out to Sergey if you are interested in an Alpine-Hurd distribution with bleeding-edge software. Reach out to Guix, if you want to help them bootstrap a 64bit Hurd. - * port gdb - * Fix bugs :) - * Notably it seems to be requiring at least 2G memory to boot. + +**TODO** + + * Fix swapping with rumpdisk + * Fix crash-dump-core server **Installing via the installer image** -The installer appears to work in qemu. Give it a shot! Let us know +The installer works fine in qemu. Give it a shot! Let us know how it works in real hardware! [[http://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/current/]] -**Installing a 64bit chroot** - -You can use the pre-built image from https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz and boot that. - -Make sure to have `debootstrap >= 1.0.128+nmu2+hurd.1` - - debootstrap --foreign --verbose --arch hurd-amd64 --include=debian-keyring,wget,curl,inetutils-ping,openssh-server,openssh-client,nano,less --keyring=/usr/share/keyrings/debian-keyring.gpg sid chroot-hurd-amd64 https://people.debian.org/~sthibault/tmp/hurd-amd64 - mkdir chroot-hurd-amd64/etc/apt/trusted.gpg.d - ln -s /usr/share/keyrings/debian-keyring.gpg chroot-hurd-amd64/etc/apt/trusted.gpg.d/ - -Then boot it, it will drop you into a shell. You'll probably want to use a nicer shell: - - bash - -You need to make / writable: - - fsysopts / --writable - -and then run the second stage of the deboostrap (and clear debs): - - /debootstrap/debootstrap --second-stage - apt clean - -set a root password: - - passwd - -Avoid core dumpings for now (not supported and hangs): - - rm -f /servers/crash - ln -s crash-kill /servers/crash - -Disable the Hurd console, buggy for now: - - export TERM=mach - nano /etc/default/hurd - # set ENABLE to 'false' - -And reboot: - - reboot-hurd - -After reboot, you'll probably want to setup network: - - vi /etc/network/interfaces - # put there this: - auto /dev/eth0 - iface /dev/eth0 inet static - address 10.0.2.15/16 - gateway 10.0.2.2 - -**Creating a 64bit disk image** - -You can use the pre-built image from https://people.debian.org/~sthibault/hurd-i386/disk-amd64.img.gz and boot that. - -To make a bootable system we really better make the disk image partitioned, and mount the partition: - - dd < /dev/zero > disk.img bs=1M count=1 seek=1000 - fdisk disk.img - # create a new primary partition spanning the whole disk: n p and just accept the defaults, and finish with w - settrans -ca disk /hurd/storeio -T typed file:disk.img - settrans -ca disk1 /hurd/storeio -T typed part:1:file:disk.img - /sbin/mke2fs -E root_owner=$UID:0 disk1 - settrans -ca chroot-hurd-amd64 /hurd/ext2fs disk1 - -(here we assume that fdisk puts the partition at sector 2048, that's indeed the -current default behavior) - -Then run the same debootstrap command as above. - -You can then make the disk bootable: - - mkdir chroot-hurd-amd64/boot/grub - tee chroot-hurd-amd64/boot/grub/grub.cfg << 'EOF' - set default="0" - set timeout=5 - menuentry "Debian GNU/Hurd amd64" { - insmod ext2 - set root=(hd0,1) - multiboot /boot/gnumach-1.8-486.gz root=part:1:device:wd0 - module /hurd/pci-arbiter.static pci-arbiter \ - --host-priv-port='${host-port}' --device-master-port='${device-port}' \ - --next-task='${disk-task}' \ - '$(pci-task=task-create)' '$(task-resume)' - module /hurd/rumpdisk.static rumpdisk \ - --next-task='${fs-task}' \ - '$(disk-task=task-create)' - module /hurd/ext2fs.static ext2fs --readonly \ - --multiboot-command-line='${kernel-command-line}' \ - --exec-server-task='${exec-task}' -T typed '${root}' \ - '$(fs-task=task-create)' - module /lib/ld-x86-64.so.1 exec /hurd/exec '$(exec-task=task-create)' - } - EOF - grub-install --modules="part_msdos ext2" --boot-directory chroot-hurd-amd64/boot disk - settrans -ga chroot-hurd-amd64 - settrans -ga disk - settrans -ga disk1 - -Then boot it, and proceed like for the chroot case. - -**Creating a pbuilder chroot** - -Here is a sample `/etc/pbuilderrc`: - - MIRRORSITE=https://people.debian.org/~sthibault/tmp/hurd-amd64 - AUTOCLEANAPTCACHE=yes - EXTRAPACKAGES="eatmydata" - if [ -z "$LD_PRELOAD" ]; then - LD_PRELOAD=libeatmydata.so - else - LD_PRELOAD="$LD_PRELOAD":libeatmydata.so - fi - export LD_PRELOAD - DEBOOTSTRAPOPTS=( - '--variant=buildd' - '--force-check-gpg' - '--keyring=/usr/share/keyrings/debian-keyring.gpg' - ) - APTKEYRINGS=(/usr/share/keyrings/debian-keyring.gpg) - -And this is needed until we get the `aptitude` package built: - - sudo ln -sf pbuilder-satisfydepends-apt /usr/lib/pbuilder/pbuilder-satisfydepends - -And then you can run `sudo pbuilder create` , `sudo pbuilder login` , `pdebuild` - -**Installing from the debian-ports archive** - -For now it's quite empty (not even gcc), but it can be debootstrapped. That will be used to build packages on the buildds. - - debootstrap --foreign --verbose --arch hurd-amd64 --extra-suites=unreleased --include=debian-ports-archive-keyring --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg sid chroot-hurd-amd64 https://deb.debian.org/debian-ports/ - -**Installing proper & more packages** - -The `people.debian.org` repository is only for bootstraping the distribution. Proper packages are getting uploaded on the usual mirror: - - deb http://deb.debian.org/debian-ports sid main - deb http://deb.debian.org/debian-ports unreleased main - **Installing a 64bit system** -In principle crosshurd should be working, one however should add this source to get more packages for now: - - deb http://people.debian.org/~sthibault/tmp/hurd-amd64 unstable - -into /etc/crosshurd/sources.list/gnu +In principle crosshurd should be working. diff --git a/open_issues/bcachefs.mdwn b/open_issues/bcachefs.mdwn index aa39bce0..330a41e1 100644 --- a/open_issues/bcachefs.mdwn +++ b/open_issues/bcachefs.mdwn @@ -12,8 +12,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] The Hurd's primary filesystem is ext2, which works but lacks modern -features. With ext2, Hurd users reguarly deal with filesystem -corruption. Ext2 does not have a journal, so Hurd users occasionally +features. Ext2 does not have a journal, so Hurd users occasionally have to deal with filesystem corruption. `fsck` can fix most of the issues (with loss of random data), but without a proper journal the Hurd currently is not a good a OS for long-term data storage. diff --git a/open_issues/runit.mdwn b/open_issues/runit.mdwn index 659b81ea..cda495ae 100644 --- a/open_issues/runit.mdwn +++ b/open_issues/runit.mdwn @@ -9,42 +9,11 @@ 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_porting]] +[[!tag open_issue]] -The `runit` package doesn't work, even its test suite doesn't finish. +In March of 2025, João got the Hurd to use +[[runit instead of sysvinit|https://lists.debian.org/debian-hurd/2025/03/msg00023.html]]. +He has so far been unsuccessful to start the [[hurd-console|hurd/console]]. -[[Thomas_Schwinge|tschwinge]] once was having a look at that, but this very -report is just from his memory, and his memory is dim... The problem *might* -either be a time stamping issue (which might be fixed by now) or it *might* be -the `select` call failing issue we're seeing from time to time. Or something -else. - -[[Harish Badrinath|harishbadrinath]] -Originally answered by Samuel Thibault: -> 120->proc_dostop_request ( 138) = 0 -> -> </snip> - -Usual issue with rpctrace: it does not support fork(). - - I've checked a backtrace in gdb, got this: - - 0x0105af6c in mach_msg_trap () - at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 - 1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140, - timeout=1000020, notify=0) at msg.c:110 - 2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0, - timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324 - 3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48 - 4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29 - 5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543 - - and main() shows up as: - - sig_unblock(sig_term); - sig_unblock(sig_child); - -> iopause(x, 2 +haslog, &deadline, &now); - sig_block(sig_term); - sig_block(sig_child); - -So it simply looks like the known "signals don't interrupt select" bug. +The Hurd project could also use the [[Shepherd|open_issues/shepherd]] +as another alternative init system. diff --git a/open_issues/tmpfs.mdwn b/open_issues/tmpfs.mdwn new file mode 100644 index 00000000..9c86db9a --- /dev/null +++ b/open_issues/tmpfs.mdwn @@ -0,0 +1,26 @@ +[[!meta copyright="Copyright © 2025 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_tmpfs]] + +For instance the X server crashes on fvwm startup, or mupdf crashes, +when /run is served by a tmpfs. + +What happens is that they create an shm (shmget, thus a file in +/run/shm/, backed by tmpfs), then map it (shmat, i.e. open/mmap/close of +the file), then remove access to it (shmctl(`IPC_RMID`), i.e. unlink the +file). + +The issue is that even if the file is still mapped, unlinking it from +tmpfs makes tmpfs `mach_port_deallocate` the memobj, which apparently +drops the object completely, and subsequent accesses to the mmap thus +fail with SIGBUS. We'd need a way for tmpfs to know about the +mappings of the pager object, to avoid shutting it down. Or a way to +keep the object alive even if tmpfs has deallocated its port to it. diff --git a/tag/open_issue.mdwn b/tag/open_issue.mdwn new file mode 100644 index 00000000..d4fac733 --- /dev/null +++ b/tag/open_issue.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2018 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="open_issue"]] + +[[!map +pages="tagged(open_issue)" +show=title]] diff --git a/tag/open_issue_tmpfs.mdwn b/tag/open_issue_tmpfs.mdwn new file mode 100644 index 00000000..7c410b8a --- /dev/null +++ b/tag/open_issue_tmpfs.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2018 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="open_issue_tmpfs"]] + +[[!map +pages="tagged(open_issue_tmpfs)" +show=title]] diff --git a/unsorted/CrossHurd.mdwn b/unsorted/CrossHurd.mdwn index 3313eba3..3e3eca8c 100644 --- a/unsorted/CrossHurd.mdwn +++ b/unsorted/CrossHurd.mdwn @@ -58,9 +58,7 @@ Set TERM variable and run native-install script. export TERM=mach ./native-install -At the end native-install wants you to reboot and run it again. Do so and remember to set the TERM variable as well. - -After the second reboot and native-install run you can remove the '-s' in the kernel line above and boot GNU/Hurd as a normal user. +You can then remove the '-s' in the kernel line above and boot GNU/Hurd as a normal user. ## <a name="Logging_in"> Logging in </a> |