diff options
Diffstat (limited to 'faq')
-rw-r--r-- | faq/64-bit.mdwn | 20 | ||||
-rw-r--r-- | faq/context_switch.mdwn | 78 | ||||
-rw-r--r-- | faq/drivers.mdwn | 7 | ||||
-rw-r--r-- | faq/other_repositories.mdwn | 2 | ||||
-rw-r--r-- | faq/reporting_bugs.mdwn | 9 | ||||
-rw-r--r-- | faq/smp.mdwn | 31 | ||||
-rw-r--r-- | faq/x-exit.mdwn | 9 | ||||
-rw-r--r-- | faq/xserver-hurd-console.mdwn | 19 |
8 files changed, 156 insertions, 19 deletions
diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn index 2e1278cb..972aafbe 100644 --- a/faq/64-bit.mdwn +++ b/faq/64-bit.mdwn @@ -13,11 +13,21 @@ License|/fdl]]."]]"""]] [[!meta title="Is there a 64-bit version?"]] -There are currently no plan for 64-bit userland for the short term, 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. The kernel support was merged into GNU Mach, the currently -missing bit is the 32/64 mig translation for kernel RPCs. +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. + +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 May 2023, the 64-bit +port works well enough to start all the essential Hurd servers, run +/bin/sh, establish TCP/IP connections, and compile C. 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. 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 new file mode 100644 index 00000000..2d090c4c --- /dev/null +++ b/faq/context_switch.mdwn @@ -0,0 +1,78 @@ +[[!meta copyright="Copyright © 2013, 2016, 2017, 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]]."]]"""]] + +[[!tag faq/support]] + +[[!meta title="I heard that context-switch on Mach is really slow?"]] + +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: + + #include <fcntl.h> + #include <semaphore.h> + #include <stdio.h> + #include <time.h> + #include <unistd.h> + #include <sys/mman.h> + + sem_t *sem1, *sem2; + + void worker1(void) { + time_t last; + int n = 0; + last = time(NULL); + while(1) { + time_t new = time(NULL); + if (new != last) { + printf("%d\n", n); + n = 0; + last = new; + } + n++; + sem_wait(sem1); + sem_post(sem2); + } + } + + void worker2(void) { + while(1) { + sem_post(sem1); + sem_wait(sem2); + } + } + + int fd; + void get_sems(void) { + void *ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); + sem1 = ptr; + sem2 = sem1+1; + } + + int main(void) { + fd = open("/tmp/foo", O_CREAT|O_TRUNC|O_RDWR, 0666); + ftruncate(fd, 4096); + + get_sems(); + sem_init(sem1, 1, 0); + sem_init(sem2, 1, 0); + + if (fork()) + worker1(); + else { + get_sems(); + worker2(); + } + } + +run on my current Linux system (a Core i5-10210U), gets about 300k switches per second on Linux. Running it on Hurd-in-kvm (which would supposedly be slower) gets about 400k switches per second. diff --git a/faq/drivers.mdwn b/faq/drivers.mdwn index 50bd4542..50ba171d 100644 --- a/faq/drivers.mdwn +++ b/faq/drivers.mdwn @@ -16,7 +16,9 @@ License|/fdl]]."]]"""]] Currently, for disks Mach integrates old drivers from Linux through some [[community/gsoc/project_ideas/driver_glue_code]], which provide IDE disk support, and we have an AHCI driver which provides [[SATA -support|faq/sata_disk_drives]]. For network boards, we use the [[DDE]] toolkit +support|faq/sata_disk_drives]]. + +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. Note however that we have of course not tested all drivers, we obviously don't even have all kinds of @@ -24,5 +26,8 @@ hardware. So we can not promise that they will all work. What probably works for sure is what we usually use: the rtl8139 and e1000 drivers for instance. Firmware loading is not implemented yet. +For graphical mode, Xorg is supported, e.g. with the vesa driver. DRM is not +supported yet. + [[microkernel/mach/gnumach/ports/Xen]] is also supported, both blkfront and netfront. diff --git a/faq/other_repositories.mdwn b/faq/other_repositories.mdwn index f8ece75f..a55ac1e3 100644 --- a/faq/other_repositories.mdwn +++ b/faq/other_repositories.mdwn @@ -11,7 +11,7 @@ License|/fdl]]."]]"""]] [[!tag faq/debian]] -If you want to use the `apt-get source` facility, make sure that +If you want to use the `apt source` facility, make sure that `/etc/apt/sources.list` contains a line like deb-src http://ftp.de.debian.org/debian unstable main diff --git a/faq/reporting_bugs.mdwn b/faq/reporting_bugs.mdwn index 25be02ef..0e556cc1 100644 --- a/faq/reporting_bugs.mdwn +++ b/faq/reporting_bugs.mdwn @@ -14,9 +14,12 @@ License|/fdl]]."]]"""]] Please try to reproduce bugs which are not obviously Hurd-specific on Debian GNU/Linux and then file them there. -If you find a genuine issue in Debian GNU/Hurd, please file it in our Alioth -bug tracker at -<http://alioth.debian.org/tracker/?atid=411594&group_id=30628&func=browse> +If you find a genuine issue in Debian GNU/Hurd, please read this +[[debian page|https://www.debian.org/Bugs/Reporting]] to learn how to +submit report a bug. If you are running Debian, then its much easier +to use the +[[reportbug|https://packages.debian.org/stable/utils/reportbug]] package. + If you find a bug in the Hurd or GNU Mach themselves, either file a bug against the respective Debian packages, or directly at <http://savannah.gnu.org/bugs/?group=hurd> diff --git a/faq/smp.mdwn b/faq/smp.mdwn index c0133b80..ee0bf53f 100644 --- a/faq/smp.mdwn +++ b/faq/smp.mdwn @@ -13,21 +13,34 @@ 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. +The Hurd servers themselves are multithreaded, so they should be able to +benefit of the parallelism brought by SMP/Multicore boxes. +This needs testing as SMP support has recently been added to Mach. [[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. +recently been enhanced to support nowadays' SMP standards like ACPI. -[[!tag open_issue_gnumach open_issue_xen]] +However, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue +code isn't SMP-safe so build with --disable-linux-groups to test SMP and use +rumpdisk to provide disk access. -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). +To build an SMP supported gnumach with kdb: +../configure --enable-ncpus=8 --enable-kdb --enable-apic --disable-linux-groups -Once this issue is solved, there are follow-up issues about +This will by default allow you to boot with one core isolated to the default +processor set, and all the other detected cpus will be in the slave processor set. +The slave processors need to be enabled per-task using RPCs to manipulate processor sets. + +See https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html for a test program +that can enable a task to use the slave processors by calling ./smp /bin/bash for example. + +Unfortunately, there are race conditions causing hangs or crashes in Mach when attempting +to boot a full SMP system, (if you revert the slave processor pinning commit). +This is what needs to be debugged one-by-one by running each translator using ./smp until +we can squash these race condition bugs. + +There are follow-up issues about [[open_issues/multiprocessing]] and [[open_issues/multithreading]]. [[Project idea|open_issues/smp]]. diff --git a/faq/x-exit.mdwn b/faq/x-exit.mdwn index 484aac13..5806cd11 100644 --- a/faq/x-exit.mdwn +++ b/faq/x-exit.mdwn @@ -16,3 +16,12 @@ License|/fdl]]."]]"""]] This is due to a missing implementation of a corner case of Posix signaling for non-root processes to root processes. One can however use the usual ctrl-alt-backspace shortcut to kill the X server. + +You just need to configure it via the file: +`/etc/X11/xorg.conf.d/xorg-ctrl-backspace.conf` + + Section "InputDevice" + Identifier "Generic KeyBoard" + Driver "kbd" + Option "XkbOptions" "terminate:ctrl_alt_bksp" + EndSection diff --git a/faq/xserver-hurd-console.mdwn b/faq/xserver-hurd-console.mdwn new file mode 100644 index 00000000..ebe2bf31 --- /dev/null +++ b/faq/xserver-hurd-console.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2022 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag faq/running]] + +[[!meta title="Cannot open keyboard (No such file or directory)"]] + +You are apparently not running the Hurd console, only the Mach console, which +Xorg does not know how to read. + +Make sure to enable the Hurd console in `/etc/default/hurd-console` |