diff options
| -rw-r--r-- | faq/64-bit.mdwn | 7 | ||||
| -rw-r--r-- | faq/context_switch.mdwn | 8 | ||||
| -rw-r--r-- | faq/debugging_translators.mdwn | 10 | ||||
| -rw-r--r-- | faq/foo_max.mdwn | 9 | ||||
| -rw-r--r-- | hurd/debugging/translator/gdb.mdwn | 10 | ||||
| -rw-r--r-- | hurd/glibc.mdwn | 4 | ||||
| -rw-r--r-- | hurd/running/gnu.mdwn | 31 | ||||
| -rw-r--r-- | open_issues/64-bit_port.mdwn | 160 |
8 files changed, 55 insertions, 184 deletions
diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn index cfda4554..d3d6d046 100644 --- a/faq/64-bit.mdwn +++ b/faq/64-bit.mdwn @@ -13,14 +13,13 @@ 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 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 the hurd-console fails to -start, which means that you cannot use X. +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. 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/foo_max.mdwn b/faq/foo_max.mdwn index cf5f80ba..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,7 +35,7 @@ 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. 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/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/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. |