diff options
55 files changed, 832 insertions, 773 deletions
@@ -0,0 +1,43 @@ +-*- mode: org -*- + +#+TITLE: the Hurd website + +The Hurd website available at https://www.gnu.org/software/hurd/ is a +static website built with [[https://ikiwiki.info/][Ikiwiki]]. This directory contains the source +files of the website. + +* Development environment + +The folling dependencies are needed to build the website + + ikiwiki, + perl, + cpan Text::Markdown, + cpan Search::Xapian, + cpan YAML::Syck, and + Texinfo + +On Debian, do something like: + +#+BEGIN_EXAMPLE +sudo apt-get install ikiwiki perl libtext-markdown-perl \ + libsearch-xapian-perl libyaml-syck-perl texinfo +#+END_EXAMPLE + +The development manifest for Guix is described in the usual [[file:manifest.scm][manifest.scm]], run: +#+BEGIN_EXAMPLE +guix shell +#+END_EXAMPLE +to enter a development environment. + +* Running the website + +To try out the website locally while you work on it, run the following +commands: + +#+BEGIN_EXAMPLE +rm -rf ../web.rendered +./render_locally +#+END_EXAMPLE + +the website is built out of tree (!) in in [[file:~/src/hurd/web.rendered][../web.rendered]]. 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/meetings.mdwn b/community/meetings.mdwn index ad43b800..d2ccd35c 100644 --- a/community/meetings.mdwn +++ b/community/meetings.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, -2015, 2016 Free Software Foundation, Inc."]] +2015, 2016, 2024 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 @@ -17,6 +17,7 @@ License|/fdl]]."]]"""]] # Past + * [[Guix_Days_2024]] * [[GNU Hackers Meeting, 2016, Rennes|ghm2016]] * [[FOSDEM_2016]] * [[DebConf15]] diff --git a/community/meetings/Guix_Days_2024.mdwn b/community/meetings/Guix_Days_2024.mdwn new file mode 100644 index 00000000..f0c110f9 --- /dev/null +++ b/community/meetings/Guix_Days_2024.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2024 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="Guix Days, 2024, Brussels"]] + +From second day [sessions' +recap](https://guix.gnu.org/blog/2024/guix-days-2024-recap): + + Hurd: Janneke Nieuwenhuizen led a discussion around GNU Hurd, which is + a microkernel-based architecture. Activity has increased in the last + couple of years, and there's support for SMP and 64-bit (x86) is work + in progress. There's lots of ideas and excitement about getting Guix + to work on Hurd. + +The [full +notes](https://lists.gnu.org/archive/html/guix-patches/2024-02/msg00035.html) +mentions a group of sixteen people attended. 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 f41c6536..127554a4 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -91,7 +91,6 @@ with". Make sure to check out the most up-to-date version on <https://darnassus.sceen.net/~hurd-web/contributing> * Teach rsync to use `*getxattr` and friends on GNU/Hurd too, to enable the -X option, so as to preserve translator entries. -* Use `thread_set_name` to add `pthread_setname_np` to glibc. * Avoid GCC trampolines: as discussed in <https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html> these happen when we pass the address of a nested function to another function. This can be seen by running `readelf -S file.o | grep GNU-stack | grep X`, for instance that happens in libdiskfs/file-exec.c, libdiskfs/io-revoke.c. We can't really use -fno-trampoline, we should instead add `void *data` parameters to iterators such as `ports_class_iterate` or `fshelp_exec_reauth`, so that the nested functions can be made mere static functions that get their information from the `void *data` parameter. * Implement `pthread_setschedparam` and `sched_setscheduler` in glibc by calling mach's `thread_policy` and `thread_priority`. * Strengthen httpfs: it should append '/' to URL automatically, it should not fallback index.html itself, etc. probably a lot more small easy issues. @@ -101,7 +100,6 @@ with". Make sure to check out the most up-to-date version on `file_get_fs_options` and `fsys_set_options` RPCs. * Extend `device_read`/`device_write` into supporting > 2TiB disk sizes. * Make `host_get_time` much more precise by using the TSC. -* Make the Hurd [[hurd/console]]'s configuration use [[xkb layout/variant instead of keymap|hurd/console/discussion]]. * Add NX / SMEP / SMAP protection support to GNU Mach. * Add use of PCID in GNU Mach. * Fix 64bit instruction set disassembling in GNU Mach's `/i386/i386/db_disasm.c` `db_disasm` function and tables. @@ -115,7 +113,6 @@ part:1:file:/home/samy/tmp/foo`). This would be libnetfs-based. * Add a tool to trace system calls, by using gnumach's Syscall-Emulation, see <http://www.gnu.org/software/hurd/gnumach-doc/Syscall-Emulation.html> * Improve our [[FUSE library|hurd/libfuse]]. * Fix our [[open_issues/symlink_translator]]. -* Add a /dev/rtc device. We can probably just create a userland trivfs-based translator `/hurd/rtc`, by taking devnode as an example, removing the `console_*` parts, and adding instead a `pioctl` part, by adding a `pioctl.defs` file (similar to the existing `rioctl.defs`) to document the expected ioctls, and implement the corresponding RPCs. * Add gnumach support for EFI memory areas report through GetMemoryMap instead of the BIOS E820. * Implement `SA_NOCLDWAIT`. It means adding an RPC to proc to implement it, and then making glibc detect when setting `SIG_IGN` on `SIGCLD`, or setting the `SA_NOCLDWAIT` flag, and in that case call into `proc`, similarly to the `S_proc_mod_stopchild` RPC. proc's `S_proc_wait` shall then wait for all children and return `ECHILD`. * Implement `lsof`. One can get inspiration from `libshouldbeinlibc/portinfo.c` for the details. @@ -163,26 +160,26 @@ 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. -* Compare testsuite results of python on hurd-i386 and hurd-amd64, to fix regressions between the former and the latter. * Check the [packages build failures differences](https://people.debian.org/~sthibault/hurd-amd64/failed_diff.txt) between hurd-i386 and hurd-amd64: they are failing on hurd-amd64 but are successful on hurd-i386. Possibly it's just a mere missing `s/hurd-i386/hurd-any/` in the debian/ directory, or a new bug that actually also affects hurd-i386 if you rebuild the package there now, but possibly it's a more profound issue in the amd64 port. * On amd64, fix memcpy (> 16 bytes) from `/dev/mem` (makes hurd-console crash) * On amd64, fix crash-core * On amd64, fix running posixtestsuite (not necessarily fixing the tests themselves, but at least make sure it doesn't crash the box ; it could still be useful to compare the output on 32bit and 64bit are the same with the same gnumach/hurd/glibc). * Settle CI for mig+gnumach+hurd+glibc. * 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 libstoreio that does not include the parted module. + * 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. * Prevent duplicate instances of `rumpdisk` from competing for the disk PCI cards (e.g. when a second one gets started from a chroot), otherwise mayhem happens. * Fix the memory consumption of `rumpdisk`. * Plug acpi shutdown event. -* Add overcommit limitation support to gnumach: limit the virtual size of processes to half of the memory + swap size. +* Add overcommit limitation support to gnumach (`RLIMIT_AS`): limit the virtual size of processes to half of the memory + swap size. Unless `MAP_NORESERVE` is passed to `mmap`. * Integrate `rumpusbdisk` with the rest of the disk translators etc. * Fix `tmpfs` losing files, see [discussion](https://lists.gnu.org/archive/html/bug-hurd/2015-02/msg00091.html). * Port `libasan`/`lsan`/`ubsan`/`libtasn` so we can use these sanitizers (youpi did some of it, pending clean/submit). @@ -190,12 +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 `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_inside_glibc.mdwn b/faq/debugging_inside_glibc.mdwn index 2a75a1a7..8577dce3 100644 --- a/faq/debugging_inside_glibc.mdwn +++ b/faq/debugging_inside_glibc.mdwn @@ -13,9 +13,7 @@ License|/fdl]]."]]"""]] In Debian, to get [[debugging]] information for glibc, you need to install the `libc0.3-dbg` package. At the place [[debugging/GDB]] looks for debugging -symbols by default (`/usr/lib/debug/lib/`), Debian's `libc0.3-dbg` stores only -the frame unwind information used for backtracing. If you want to step into -glibc while debugging, you need to add `LD_LIBRARY_PATH=/usr/lib/debug` to -debugged program's environment (`set env VAR value` from the GDB command line). -If that still does not work, try `LD_PRELOAD=/usr/lib/debug/libc.so.0.3` -instead. +symbols by default (`/usr/lib/debug/.build-id`), Debian's `libc0.3-dbg` stores only +the frame unwind information used for backtracing. + +You also need to download the source code with `apt source glibc` and `cd` into it for `gdb` to be able to find and show it, or use `set directories` inside gdb, or put it in your `.gdbinit` 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 new file mode 100644 index 00000000..ccd09904 --- /dev/null +++ b/faq/foo_max.mdwn @@ -0,0 +1,76 @@ +[[!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 faq/general]] + +[[!meta title="Why not just defining `PATH_MAX`, `MAXPATHLEN`, ... `FOO_MAX` and be done?"]] + +More technical details are described in [`PATH_MAX` Is Tricky](https://eklitzke.org/path-max-is-tricky) + +For porting guidelines, see [[hurd/porting/guidelines#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL]] + +# Is it really standard not to define them? + +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 +it, but some software still add `+1`. Sometimes `PATH_MAX` is even understood as +the filename sections of paths, which is actually `NAME_MAX`, which *is* indeed +limited by filesystems constraints, but then it is filesystem-dependent, and +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 `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)` 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 +actually "wrong" on Linux: + + $ printf '#include <limits.h>\nPATH_MAX' | cpp -P + $ d=0123456789; for i in `seq 1 1000`; do mkdir $d; cd $d 2>/dev/null; done + $ pwd | wc -c + +Using such paths lead to various broken software, we could for instance notice: + +* nautilus crashes because of unhandled signal 8, arithmetic exception +* tar can create an archive containing such paths, but cannot untar it +* filelight just ignores the path +* gdb refuses to work + +Using a large `PATH_MAX` value just *hides* these bugs under the +carpet. Attackers will happily try to exploit them. + +# Can't it just be defined to `PTRDIFF_MAX`? + +A lot of programs which blindly use `FOO_MAX` as allocation size would then just +at best either not compile or at worse compile but fail or segfault at execution. + +# These also imply ABI problems + +Exposing a hardcoded limitation like `FOO_MAX` also means hard-defining them +into binaries, making them part of the ABI, and then a hell to change. See for +instance Windows which has been stuck with `MAX_PATH` being 260. Some libraries +(e.g. libusb1) even expose them in their own ABI, thus making the increase a +very nasty flag-day. diff --git a/hurd/bootstrap.mdwn b/hurd/bootstrap.mdwn index c77682b9..76ad0dc5 100644 --- a/hurd/bootstrap.mdwn +++ b/hurd/bootstrap.mdwn @@ -19,101 +19,111 @@ this text. --> # State at the beginning of the bootstrap -Please note that as of May 2024 this document is out of date. It does -not explain how rumpdisk or the pci-arbitor is started. Also consider -reading about [[Serverboot V2|open_issues/serverbootv2]], which -is a new bootstrap proposal. +Also consider reading about [[Serverboot V2|open_issues/serverbootv2]], which is +a new bootstrap proposal. After initializing itself, GNU Mach sets up tasks for the various bootstrap translators (which were loader by the GRUB bootloader). It notably makes variables replacement on their command lines and boot script function calls (see -the details in `gnumach/kern/boot_script.c`). For instance, if the GRUB -bootloader has the following configuration: +the details in `gnumach/kern/boot_script.c`). For instance, the GRUB +bootloader can have the following typical configuration: multiboot /boot/gnumach-1.8-486-dbg.gz root=device:hd1 console=com0 - module /hurd/ext2fs.static ext2fs --readonly \ - --multiboot-command-line='${kernel-command-line}' \ + module /hurd/pci-arbiter.static pci-arbiter --host-priv-port='${host-port}' \ --device-master-port='${device-port}' \ + --next-task='${acpi-task}' \ + '$(pci-task=task-create)' '$(task-resume)' + module /hurd/acpi.static acpi \ + --next-task='${disk-task}' \ + '$(acpi-task=task-create)' + 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}' \ - '$(task-create)' '$(task-resume)' + '$(fs-task=task-create)' module /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)' -GNU Mach will first make the `$(task-create)` function calls, and thus create a -task for the ext2fs module and a task for the exec module (and store a port on -that task in the `exec-task` variable). +GNU Mach will first make the `$(task-create)` function calls, and thus create +a series of tasks for the various modules, and assign to the `pci-task`, +`acpi-task`, `disk-task`, and `fs-task` variables the task ports for each of +them. None of these tasks is started yet. It will then replace the variables (`${foo}`), i.e. * `${kernel-command-line}` with its own command line (`root=device:hd1 console=com0`), * `${host-port}` with a reference to the GNU Mach host port, * `${device-port}` with a reference to the GNU Mach device port, -* `${exec-task}` with a reference to the exec task port. +* `${acpi-task}` with a reference to the acpi task port, and similarly for all other tasks. * `${root}` with `device:hd1` This typically results in: - task loaded: ext2fs --readonly --multiboot-command-line=root="device:hd1 console=com0" --host-priv-port=1 --device-master-port=2 --exec-server-task=3 -T typed device:hd1 + task loaded: pci-arbiter --host-priv-port=1 --device-master-port=2 --next-task=3 + task loaded: acpi --next-task=1 + task loaded: rumpdisk --next-task=1 + task loaded: ext2fs --readonly --multiboot-command-line=root="device:sd1 console=com0" --exec-server-task=1 -T typed device:sd1 task loaded: exec /hurd/exec + (You will have noticed that `/hurd/exec` is not run directly, but through `ld.so.1`: Mach only knows to run statically-linked ELF binaries, so we could -either load `/hurd/exec.static`, or load the dynamic loader `ld.so.1` and tell -it to load `/hurd/exec`) +either load `/hurd/exec.static` directly, or load the dynamic loader `ld.so.1` +and tell it to load `/hurd/exec`, which will be readable once `ext2fs.static` is +started) GNU Mach will eventually make the `$(task-resume)` function calls, and thus -resume the ext2fs task only. - -This starts a dance between the bootstrap processes: `ext2fs`, `exec`, `startup`, -`proc`, and `auth`. Indeed, there are a few dependencies between them: `exec` needs -`ext2fs` working to be able to start `startup`, `proc` and `auth`, and `ext2fs` needs to -register itself to `startup`, `proc` and `auth` so as to appear as a normal process, -running under uid 0. +resume the `pci-arbiter` task only. -The base principle is that `ext2fs` has a nul bootstrap port set to while other -translators will have a non-nul bootstrap port, with which they will discuss. We -thus have a hierarchy between the bootstrap processes. `ext2fs` is at the root, -`exec` and `startup` are its direct children, and `auth` and `port` are direct -children of `startup`. - -Usually the bootstrap port is used when starting a translator, see +Usually the bootstrap ports of translators is used when starting them, see `fshelp_start_translator_long`: the parent translator starts the child and sets its bootstrap port. The parent then waits for the child to call `fsys_startup` on the bootstrap port, for the child to provide its control port, and for the parent to provide the FS node that the child is translator for. -For the bootstrap translators, the story is extended: +But here when `pci-arbiter` initializes itself, it notices that its bootstrap +port is nul (it is started by the kernel, not a filesystem) so it knows that it +is alone and can only rely on the kernel. It initializes itself and parses the +arguments, and since it is given a `next-task`, it uses `task_set_special_port` +to pass a send right to its own control port to that next task (here `acpi`) as +bootstrap port, and uses `task_resume` to start it. + +Similarly, `acpi` initializes itself, gives a send right to `rumpdisk` and +starts it. + +`rumpdisk` does the same, so that eventually `ext2fs` starts, with all of +`pci-arbiter`, `acpi` and `rumpdisk` ready to reply to `device_open` requests on +the `pci`, `acpi`, and disks device names. -* Between `ext2fs` and `startup`: `startup` additionally calls `fsys_init`, to +Now that `ext2fs` starts, a dance begin between the remaining bootstrap +processes: `ext2fs`, `exec`, `startup`, `proc`, and `auth`. Indeed, there are +a few dependencies between them: `exec` needs `ext2fs` working to be able to +start `startup`, `proc` and `auth`, and `ext2fs` needs to register itself to +`startup`, `proc` and `auth` so as to appear as a normal process, running under +uid 0. + +They will register to each other the following way: + +* Between `ext2fs` and `startup`: `startup` calls `fsys_init`, to provide `ext2fs` with `proc` and `auth` ports. * Between `startup` and `proc`: `proc` just calls `startup_procinit` to hand over a `proc` port and get `auth` and `priv` ports. * Between `startup` and `auth`: `auth` calls `startup_authinit` to hand over an `auth` port and get a `proc` port, then calls `startup_essential_task` to notify `startup` that the boot can proceed. -* For translators before `ext2fs`, the child calls `fsys_startup` to pass over -the control port of `ext2fs` (instead of its own control port, which is useless -for its parent). This is typically done in the `S_fsys_startup` stub, simply -forwarding it. The child also calls `fsys_init` to pass over the `proc` and -`auth` ports. Again, this is typically done in the `S_fsys_init` stub, simply -forwarding them. +* For the series of translators before `ext2fs`, each task calls `fsys_startup` +to pass over the control port of `ext2fs` to the previous task (instead of +its own control port, which is useless for it). This is typically done in the +`S_fsys_startup` stub, simply forwarding it. It also calls `fsys_init` to +pass over the `proc` and `auth` ports. Again, this is typically done in the +`S_fsys_init` stub, simply forwarding them. With that in mind, the dance between the bootstrap translators is happening as described in the next sections. -# Initialization of translators before ext2fs - -We plan to start pci-arbiter and rumpdisk translators before ext2fs. - -pci-arbiter's `main` function parses the arguments, and since it is given a disk -task port, it knows it is a bootstrap translator and thus initializes the -machdev library. `machdev_trivfs_init` resumes the disk task. - -rumpdisk's `main` function parses the arguments, and since it is given a FS task -port, it knows it is a bootstrap translator, and thus `machdev_trivfs_init` -resumes the FS task. - # ext2fs initialization ext2fs's `main` function starts by calling `diskfs_init_main`. @@ -127,7 +137,8 @@ ext2fs bootstrap port to `MACH_PORT_NULL`: it is the bootstrap filesystem which will be in charge of dancing with the exec and startup translator. `diskfs_init_main` then initializes the libdiskfs library and spawns a thread to -manage libdiskfs RPCs. +manage libdiskfs RPCs. It also notices that the filesystem is given a kernel +command line, i.e. this is the bootstrap filesystem. ext2fs continues its initialization: creating a pager, opening the hypermetadata, opening the root inode to be set as root by libdiskfs. @@ -137,7 +148,7 @@ by the libdiskfs library. # libdiskfs bootstrap -Since the bootstrap port is `MACH_PORT_NULL`, `diskfs_startup_diskfs` calls +Since this is the bootstrap filesystem, `diskfs_startup_diskfs` calls `diskfs_start_bootstrap`. `diskfs_start_bootstrap` starts by creating a open port on itself for the @@ -272,13 +283,26 @@ on its bootstrap port, i.e. rumpdisk. rumpdisk's `trivfs_S_fsys_init` gets called from the `fsys_init` call from ext2fs. It calls `fsys_init` on its bootstrap port. +# acpi getting initialized + +acpi's `trivfs_S_fsys_init` gets called from the `fsys_init` call from +rumpdisk. It calls `fsys_init` on its bootstrap port. + # pci-arbiter getting initialized pci-arbiter's `trivfs_S_fsys_init` gets called from the `fsys_init` call from rumpdisk. It gets the root node of ext2fs, sets all common ports, and install -pci-arbiter in the ext2fs FS as translator for `/servers/bus/pci`. +itself in the ext2fs FS as translator for `/servers/bus/pci`. + +It eventually calls `startup_essential_task` to tell startup that it is ready, +and requests shutdown notifications. + +# back to acpi initialization + +It gets the root node of ext2fs, sets all common ports, and install +itself in the ext2fs FS as translator for `/servers/acpi`. It eventually calls `startup_essential_task` to tell startup that it is ready, and requests shutdown notifications. @@ -286,7 +310,7 @@ and requests shutdown notifications. # back to rumpdisk initialization It gets the root node of ext2fs, sets all common ports, and install -rumpdisk in the ext2fs FS as translator for `/dev/disk`. +itself in the ext2fs FS as translator for `/dev/disk`. It eventually calls `startup_essential_task` to tell startup that it is ready, and requests shutdown notifications. @@ -304,7 +328,7 @@ system is shutting down. # startup monitoring bootstrap progress -As mentioned above, the different essential tasks (pci-arbiter, rumpdisk, ext2fs, proc, auth, exec) +As mentioned above, the different essential tasks (pci-arbiter, acpi, rumpdisk, ext2fs, proc, auth, exec) call `startup_essential_task` when they are ready. startup's `S_startup_essential_task` function thus gets called each time, and startup records each of them as essential, monitoring their death to crash the whole 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/Guix.mdwn b/hurd/running/Guix.mdwn index 64f9d0e7..30b7b62a 100644 --- a/hurd/running/Guix.mdwn +++ b/hurd/running/Guix.mdwn @@ -9,11 +9,59 @@ GNU/Hurd support has been integrated in Guix. --- # Documentation -As Hurd support is integrated in Guix, the official documentation (<https://guix.gnu.org/en/manual/devel/>) also works for Hurd. +As Hurd support is integrated in Guix, the [official +documentation](https://guix.gnu.org/manual/en/html_node/) also works +for Hurd. -Guix has even support in its configuration language for creating Hurd VMs from a running Guix system (<https://guix.gnu.org/en/manual/devel/en/guix.html#The-Hurd-in-a-Virtual-Machine>). - ---- # Status -At the time of writing, the official Guix manual says that "This configuration is experimental and under development. The easiest way for you to give it a try is by setting up an instance of hurd-vm-service-type on your GNU/Linux machine (see hurd-vm-service-type). See Contributing, on how to help!" (<https://guix.gnu.org/en/manual/devel/en/guix.html#GNU-Distribution>). +At the time of writing the Guix manual says "This configuration is +experimental and under development. … See +[Contributing](https://guix.gnu.org/manual/en/html_node/Contributing.html), +on how to help!" + +The easiest way to try Guix/Hurd is by setting up a Guix Childhurd +instance on your GNU/Linux machine. + +Cross-building to x86_64-gnu [has just landed on Guix +master](https://lists.gnu.org/archive/html/guix-patches/2024-12/msg00199.html). + +# Childhurds + +Guix' operating-system description supports a [`hurd-vm` +or *childhurd* service](https://guix.gnu.org/manual/devel/en/html_node/Virtualization-Services.html#The-Hurd-in-a-Virtual-Machine). +Specifying the `hurd-vm-service-type` in the `services` of an `operating system` description + + (operating-system + ;; … + (services + (list + ;; Add the 'hurd-vm' service + (service hurd-vm-service-type) + … + %base-services))) + +automagically builds and starts a `Childhurd` that can be also used +for +[offloading](https://guix.gnu.org/manual/en/html_node/Daemon-Offload-Setup.html) +Hurd builds. + +# Rumpdisk and NetDDE support + +Guix supports NetDDE and Rumpdisk, also [running in a +Childhurd](https://toot.aquilenet.fr/@civodul/110848429561223704). + +# Guix/Hurd on Real Iron + +Guix/Hurd has been [ installed on a Thinkpad +X60](https://todon.nl/@janneke/110451493405777898). + +The Guix installer supports cross-installation support for Guix/Hurd. + +Of course Guix/Hurd can also be installed from a running GNU/Linux +system by doing something like: + + guix system init hurd.scm /hurd + +An blog post was published about running [Guix/Hurd on a Thinkpad +X60](https://guix.gnu.org/blog/2024/hurd-on-thinkpad/). 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/running/virtualbox.mdwn b/hurd/running/virtualbox.mdwn index b48f7ebd..cf9a5870 100644 --- a/hurd/running/virtualbox.mdwn +++ b/hurd/running/virtualbox.mdwn @@ -11,8 +11,23 @@ License|/fdl]]."]]"""]] [[!meta title="VirtualBox"]] -<http://www.virtualbox.org/> - +Some people are very familiar with using VirtualBox to run virtual machines of OS +like GNU/Linux, Windows, etc. Hurd CAN also be run with VirtualBox normally, and +the way is very similar to running other OS with it. The main problem may be that +Hurd may not support as many emulated hardware as others, which is also a good +point to help us. + +This also provides a good opportunity for people who want to play with Hurd on +every other OS which can run VirtualBox. You can absolutely run and develop Hurd +without switching your current OS or running a nest Hurd in another virtual machine. + +If you happen to have experience on developing GNU/Linux on other OS like +Windows, you can develop Hurd smoothly just like before. We might recommend that +you use a FSF approved operating system to get better experience of developing +Hurd, but if for some reason you are stuck using Windows, this won't be an +unsolvable obstacle. + +You can download VirtualBox at <http://www.virtualbox.org/>. # Installation 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.mdwn b/hurd/translator.mdwn index 324c5f8c..fe669a12 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -121,6 +121,7 @@ The [[concept|concepts]] of translators creates its own problems, too: * [[term]] * [[checkperms]] * [[usermux]] +* [[rtc]] * ... diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index 9be6c885..3baf6b03 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -617,18 +617,6 @@ That would be a nice improvement, but only after writeback throttling is impleme separate partitions is a way to alleviate them -## `ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: Assertion `!diskfs_readonly' failed.` - -### IRC, freenode, #hurd, 2014-02-22 - - <gg0> login: init: notifying pfinet of shutdown...init: notifying tmpfs - none of shutdown...init: notifying tmpfs none of shutdown...init: - notifyi. - <gg0> ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: - Assertion `!diskfs_readonly' failed. - <gg0> In tight loop: hit ctl-alt-del to reboot - - # Documentation * <http://e2fsprogs.sourceforge.net/ext2.html> 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/translator/rtc.mdwn b/hurd/translator/rtc.mdwn new file mode 100644 index 00000000..7a917b46 --- /dev/null +++ b/hurd/translator/rtc.mdwn @@ -0,0 +1,31 @@ +[[!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]]."]]"""]] + +The *rtc* translator implements a real-time clock driver. It can be used to add +the `rtc` device files, with those files, we can access the underlying +real-time clock using `ioctl()`. The description of `ioctl()` can be found +[here](https://www.gnu.org/software/libc/manual/html_node/IOCTLs.html). + +The operation macros are required to access the real-time clock. They are +defined as `RTC_*` in `hurd/rtc.h`. + +The `hwclock` command from `util-linux` can use the `rtc` device files to +access the real-time clock devices. + +# Usage Example +Setup a `rtc` device file in `/tmp`: + + settrans -c /tmp/rtc /hurd/rtc + +Read the time value through the `rtc` device file: + + int fd = open("/tmp/rtc", O_RDONLY); + struct rtc_time time; + ioctl(fd, RTC_RD_TIME, &time); 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]]? @@ -57,12 +57,8 @@ So, you are interested in contributing to the GNU Hurd project? Welcome! Every single contribution is very much encouraged. Please read our [[detailed recommendations about how to contribute|contributing]]. -See our [[source_repositories]] for the source code. - -## Access to a GNU/Hurd System - -We provide accounts on our [[public_Hurd_boxen]], and there are also several GNU/Hurd [[Distributions|hurd/running/distrib]] that allow for -[[hurd/running/QEMU]] emulation. +Follow section [[Running_the_Hurd|/index#run]] to run the Hurd. See our +[[source_repositories]] for the source code. --- # Getting Help @@ -78,19 +74,36 @@ question, feel free to ask on a mailing list or on IRC. --- <a name="run"> </a> -# Running the Hurd -The most functional distribution of the Hurd is the one provided by Debian. -Find more information about it at the +<!-- Use HTML h1 with an id to create an anchor for the section. --> +<h1 id="run"> Running the Hurd </h1> + +Running the Hurd may not be as hard as some people think. There are +[[various_ways|hurd/running]]. The easiest one might be using a +virtual machine platform. We also provide accounts on our [[public_Hurd_boxen]]. + +Four of them are + +* Installing a [[GNU/Hurd_distribution|hurd/running/distrib]] to a real machine. +* Running it in [[Xen|microkernel/mach/gnumach/ports/xen]]. +* Running it with [[QEMU|hurd/running/qemu]]. +* Running it with [[VirtualBox|hurd/running/virtualbox]], if you are familiar + with VirtualBox or using an OS which is difficult to run QEMU like Windows. + +For a virtual machine, you can use either a +[[pre-installed_qemu_image|hurd/running/qemu]] +or a [[LiveCD|hurd/running/live_cd/]]. The pre-installed image (converted +to proper format) can be used as a hard disk in a virtual machine to skip the +installation step and run the Hurd directly. The LiveCD is just like the one of +other OS. + +There are also various [[GNU/Hurd_distributions|hurd/running/distrib]] which you +can choose from. The most functional one is the one provided +by Debian. It's a good choice for a start, whether you have experience with it, +or if you can't decide which one to choose. It provides both a pre-installed +image and a LiveCD. Find more information about it at the [Debian GNU/Hurd website](http://www.debian.org/ports/hurd/hurd-install). -Along with it there are [[various_ways|hurd/running]] to run a GNU/Hurd system. -Three of them are - -* Installing a [[GNU/Hurd_distribution|hurd/running/distrib]], -* Running it [[in_Xen|microkernel/mach/gnumach/ports/xen]] and -* Starting a Hurd [[QEMU_image|hurd/running/qemu]] or [[LiveCD|hurd/running/live_cd/]]. - And these web pages are a living proof of the usability of the Hurd, as they are rendered on a [[Debian_GNU/Hurd|hurd/running/debian]] system. diff --git a/manifest.scm b/manifest.scm new file mode 100644 index 00000000..113bbd9e --- /dev/null +++ b/manifest.scm @@ -0,0 +1,15 @@ +;; GNU Guix development manifest. To create development environment, run +;; +;; guix shell +;; +;; or something like +;; +;; guix shell --pure --manifest=manifest.scm ... + +(specifications->manifest + (list "ikiwiki" + "perl" + "perl-search-xapian" + "perl-text-markdown" + "perl-yaml-syck" + "texinfo")) 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/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn index 740949e0..4c800e6b 100644 --- a/microkernel/mach/mig/documentation.mdwn +++ b/microkernel/mach/mig/documentation.mdwn @@ -85,6 +85,7 @@ pp. 67--77." * MIG *in action*: [[hurd/io_path]]. + * [[What is mig-mutate.h?|mig-mutate]] ## IRC, freenode, #hurd, 2013-09-04 diff --git a/microkernel/mach/mig/documentation/mig-mutate.mdwn b/microkernel/mach/mig/documentation/mig-mutate.mdwn new file mode 100644 index 00000000..dd027a04 --- /dev/null +++ b/microkernel/mach/mig/documentation/mig-mutate.mdwn @@ -0,0 +1,138 @@ +[[!meta copyright="Copyright © 2024 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]]."]]"""]] + +The text in this page is based on the following code (from `$(hurd)/rtc/mig-mutate.h`): + + #define IO_INTRAN trivfs_protid_t trivfs_begin_using_protid (io_t) + #define IO_INTRAN_PAYLOAD trivfs_protid_t trivfs_begin_using_protid_payload + #define IO_DESTRUCTOR trivfs_end_using_protid (trivfs_protid_t) + #define IO_IMPORTS import "libtrivfs/mig-decls.h"; + +First, a brief description of what a protid is. Hurd translators +typically represent "files" internally with three kinds of distinct +structures: + +1. **node** -- these are filesystem nodes, same concept as an "inode". +2. **peropen** -- this keeps the data "per open" of the file and +corresponds to an "open file description" in POSIX. Things like +current I/O offset and the open mode (`O_READ | O_WRITE` ...) live here. +3. **protid** (or "credential") -- describes a specific "user" (UIDs/GIDs) +on behalf of whom the file is being accessed. + +A protid has a pointer to the peropen, and the peropen has a pointer +to the node. A node can have multiple peropens referring to it (when +the file has been opened multiple times), and a peropen can have +multiple protids referring to it (when processes running as different +users share an open file description, e.g. your shell and a sudo +invocation share the pts). In trivfs, there's only a single node, so +the concept is deemphasized. + +The concept of protid doesn't exist in classic Unix, since a +monolithic kernel can just directly see which UID the current process +runs as. But Mach IPC is (intentionally) designed in a way that it's +inherently impossible to see "who's asking", so instead we represent +differently-privileged callers with different handles (protids) that +refer to the same peropen, and then we check which protid the request +was made on. + +It is a protid that corresponds to an Mach port (`io_t`, `file_t`, ...), +though the client side doesn't need to care. + +When an incoming request arrives, the thing you actually receive in a +message is the port name (ignoring protected payloads for now). What +you actually want is the protid that it corresponds to. + +trivfs has the API to look up the protid given the port, namely +`trivfs_begin_using_protid` (which wraps `ports_lookup_port` from +libports), and you could call that yourself: + + kern_return_t + rtc_S_foobar (io_t port, int foo, int *bar) + { + error_t err = 0; + struct trivfs_protid *cred = trivfs_begin_using_protid (port); + + if (!cred) + /* The request came in on a port that we listen for incoming + * messages on, but it doesn't correspond to a protid. Must + * be some other kind of port. */ + return EOPNOTSUPP; + + if (!(cred->po->openmodes & O_READ)) + { + err = EBADF; + goto out; + } + + do something with cred... + + out: + trivfs_end_using_protid (cred); + return err; + } + +But since we already have a code generator (MIG), why not make it +generate the conversion logic for us as well. And so, in MIG, when +defining a type, you can provide `intran` and `outtran` and +`destructor` function names, and MIG will generate the calls for you. + +So the proper MIG way to (but see below about the Hurd way) to do the +thing that you're trying to do would be to define your own flavor of +Mach ports, say `rtc_port_t`, like this: + + type rtc_port_t = mach_port_t + intran: trivfs_protid_t trivfs_begin_using_protid (io_t) + destructor: trivfs_end_using_protid (trivfs_protid_t); + +and then use that type in the routine definitions. MIG would then call +`trivfs_begin_using_protid` and `trivfs_end_using_protid` in the server-side +generated functions, only passing `trivfs_protid_t` (which is a typedef +for `struct trivfs_protid *`, since MIG can't deal with the full C type +notation) to your implementation. The downside of this is that it the +implementation details of the server leak into the API definition, and +for instance you'd have to edit the `.defs` if you switch the server +from trivfs to netfs. + +You can find some documentation about this MIG feature under "Type +Translation Information" on page 17 of the [Mach 3 Server Writer’s +Guide](http://shakthimaan.com/downloads/hurd/server_writer.pdf), +but of course keep in mind that the guide was written a long time +ago, about a much older version of MIG, without any of the Hurd +additions/specifics/best practices. + +Then, `hurd_types.defs` has this: + + type io_t = mach_port_copy_send_t + #ifdef IO_INTRAN + intran: IO_INTRAN + intranpayload: IO_INTRAN_PAYLOAD + #else + #ifdef HURD_DEFAULT_PAYLOAD_TO_PORT + intranpayload: io_t HURD_DEFAULT_PAYLOAD_TO_PORT + #endif + #endif + #ifdef IO_OUTTRAN + outtran: IO_OUTTRAN + #endif + #ifdef IO_DESTRUCTOR + destructor: IO_DESTRUCTOR + #endif + ; + +(and same for all the other types of ports, e.g. `FILE_INTRAN`, +`SHUTDOWN_DESTRUCTOR` etc) + +which lets you use the standard `io_t` type while plugging in your own +`intran/intranpayload/outtran/destructor` functions, in a way that +doesn't leak into the `defs`. You only have to define the macros in your +local `mig-mutate.h` header in your server. + +The content in this page is from [bug-hurd mail list](https://mail.gnu.org/archive/html/bug-hurd/2024-11/msg00045.html) with some modifications. 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 a5d206e5..01a2aad5 100644 --- a/open_issues/64-bit_port.mdwn +++ b/open_issues/64-bit_port.mdwn @@ -13,173 +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/arm_port.mdwn b/open_issues/arm_port.mdwn index 88ef0e9c..cc33b074 100644 --- a/open_issues/arm_port.mdwn +++ b/open_issues/arm_port.mdwn @@ -413,45 +413,37 @@ Copy dt.dtb, gnumach, gnumach-tracing and all modules on the sd card. The tracing version of gnumach is obtained by cherrypicking the relative commit in a gnumach tree and rebuilding gnumach: -``` -git cherry-pick ee177f52680116538192b2c0c5d9a08e174c007f -``` + git cherry-pick ee177f52680116538192b2c0c5d9a08e174c007f Create the file boot.cmd on the smartcard: -``` -if itest $trace != 0; then load mmc 0:1 0x42000000 gnumach-tracing; else load mmc 0:1 0x42000000 gnumach; fi -load mmc 0:1 0x60000000 $module -load mmc 0:1 0x42200000 dt.dtb - -fdt addr 0x42200000 -fdt resize -fdt set /chosen bootargs "foo=bar" -fdt set /chosen \#address-cells <0x2> -fdt set /chosen \#size-cells <0x2> -fdt mknod /chosen module@0x60000000 -fdt set /chosen/module@0x60000000 compatible "multiboot,kernel" "multiboot,module" -fdt set /chosen/module@0x60000000 reg <0x0 0x60000000 0x0 0x04000000> -fdt set /chosen/module@0x60000000 bootargs "$module "'${host-port} -${device-port} $(task-create) $(task-resume)' - -booti 0x42000000 - 0x42200000 -``` + if itest $trace != 0; then load mmc 0:1 0x42000000 gnumach-tracing; else load mmc 0:1 0x42000000 gnumach; fi + load mmc 0:1 0x60000000 $module + load mmc 0:1 0x42200000 dt.dtb + + fdt addr 0x42200000 + fdt resize + fdt set /chosen bootargs "foo=bar" + fdt set /chosen \#address-cells <0x2> + fdt set /chosen \#size-cells <0x2> + fdt mknod /chosen module@0x60000000 + fdt set /chosen/module@0x60000000 compatible "multiboot,kernel" "multiboot,module" + fdt set /chosen/module@0x60000000 reg <0x0 0x60000000 0x0 0x04000000> + fdt set /chosen/module@0x60000000 bootargs "$module "'${host-port} + ${device-port} $(task-create) $(task-resume)' + + booti 0x42000000 - 0x42200000 Compile it with: -``` -mkimage -C none -A arm -T script -d boot.cmd boot.scr -``` + mkimage -C none -A arm -T script -d boot.cmd boot.scr Boot into Das u-boot, interrupt automatic booting to set the variables before: -``` -trace=0 -module=module-hello -boot -``` + trace=0 + module=module-hello + boot modify trace to a different number to start the version of gnumach compiled with tracing. 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/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn deleted file mode 100644 index d9f05999..00000000 --- a/open_issues/clock_gettime.mdwn +++ /dev/null @@ -1,348 +0,0 @@ -[[!meta copyright="Copyright © 2011, 2013, 2014 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="clock_gettime"]] - -[[!tag open_issue_glibc open_issue_gnumach]] - -Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel) - -It could be a mere matter of extending the -[[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]: -add it to -`mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and -make `clock_gettime` use it. - -BTW, also make `gettimeofday()` use it, since it's way more efficient and some -applications assume that it is. - -What about adding a nanosecond-precision clock, too? --[[tschwinge]] - - -# IRC, freenode, #hurd, 2011-08-26 - - < pinotree> youpi: thing is: apparently i found a simple way to have a - monotonic clock as mmap-able device inside gnumach - < pinotree> currently, in kern/mach_clock.c there's a variable 'time', - which gets increased on clock interrupt, and optionally modified by - host_set_time - < pinotree> () - < pinotree> if i add a new variable next to it, only increasing it on - interrupt but not modifying it at all otherwise, would that give me a - monotonic clock? - < pinotree> at least on sme basic tests i did, it seems it could work that - way - < youpi> yes, it should work - < braunr> sure - < youpi> and that's the way I was considering implementing it - - -# IRC, freenode, #hurd, 2011-09-06 - - <pinotree> yeah, i had a draft of improved idea for also handling - nanoseconds - <tschwinge> pinotree: Ah, nice, I thought about nanoseconds as well. - <tschwinge> pinotree, youpi: This memory page is all-zero by default, - right? - <tschwinge> Can't we then say that its last int is a version code, and if - it is 0 (as it is now), we only have the normal mapped time field, if it - is 1, we also have the monotonic cliock and ns precision on address 8 and - 16 (or whatever)? - <tschwinge> In case that isn't your plan anyway. - <youpi> it's all-zero, yes - <tschwinge> Or, we say if a field is != 0 it is valid. - <youpi> making the last int a version code limits the size to one page - <youpi> I was thinking a field != 0 being valid is simpler - <youpi> but it's probably a problem too - <youpi> in that glibc usually caches whether interfaces are supported - <tschwinge> Wrap-around? - <youpi> for some clocks, it may be valid that the value is 0 - <youpi> wrap-around is another issue too - <tschwinge> Well, then we can do the version-field thing, but put it right - after the current time field (address 8, I think)? - <youpi> yes - <youpi> it's a bit ugly, but it's hidden behind the structure - <tschwinge> It's not too bad, I think. - <youpi> yes - <tschwinge> And it will forever be a witness of the evolving of this - map_time interface. :-) - - -# IRC, freenode, #hurd, 2013-02-11 - -In context of [[select]]. - - <pinotree> braunr: would you send for review (and inclusion) your - time_data_t addition? - <pinotree> this way we could add nanosecs-based utime rpc (and then their - implementation in libc) - <braunr> pinotree: it's part of the hurd branch - <braunr> do you want it sent separately ? - <pinotree> yeah - <braunr> ok - <braunr> let me get it right first :) - <pinotree> sure :) - - -## IRC, freenode, #hurd, 2013-02-12 - - <braunr> pinotree: - https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a - <pinotree> uh nice - <pinotree> will need two small inline functions to convert time_data_t <-> - timespec, but that's it - <braunr> hm right - <braunr> i could have thought about it - <braunr> but i'll leave it for another patch :p - <pinotree> oh sure, no hurry - - -## IRC, freenode, #hurd, 2013-02-19 - - <youpi> braunr: about time_data_t, I get it's needed that it be an array - <youpi> so it can be passed by reference, not by value? - <braunr> by address, yes - <braunr> that's the difference between array and struct - - -## IRC, freenode, #hurd, 2013-02-25 - - <youpi> braunr: why did you want to see time_data passed as pointer, not as - struct? - <braunr> to microoptimize - <braunr> the struct is 2 64-bit integers - <youpi> well, we already pass structs along in a few cases, - e.g. io_statbuf_t, rusage_t, etc. - <youpi> be it written t[0].sec or t->sec, it seems odd - <youpi> copying 2 64bit integers is not much compared to the potential for - bugs here - <braunr> bugs ? - <youpi> yes, as in trying to access t[1], passing a wrong pointer, etc. - <youpi> or the reader frowning on "why is this case different than the - others?" - <braunr> well, i'm already usually frowning when i see what mig does .. - <youpi> right - <youpi> on the plus side, it's only the client side, i.e. mostly glibc, - which sees the t[0] - <braunr> and the practice established by my patch is to convert to struct - timespec as soon as possible - <braunr> the direct use of this type is therefore limited - <youpi> could we define time_data_t as a struct time_data * instead of - struct time_data[1] ? - <youpi> (in the.h) - <youpi> that would make more sense to define a struct time_data, and pass a - pointer to it - <braunr> i'm not sure - <braunr> the mach server writing guide was very clear about array implying - a C array too - <braunr> and i remember having compilation problems before doing that - <braunr> but i don't remember their nature exactly - <youpi> I'm not sure to understand what you said about converting to struct - timespec - <youpi> what makes it not possible now? - <youpi> and what is the relation with being an array or a pointer? - <braunr> concerning struct timespec, what i mean is that the functions - called by the mig stub code directly convert time_data_t to a struct - timespec (which is the real type used throughout the hurd code) - <braunr> about the rest, i'm not sure, i'd have to try again - <braunr> mig just assumes it's an array - <youpi> and why not just using struct timespec? - <youpi> (for the mig type too) - <braunr> my brain can't correctly compute variable sized types in mig - definition files - <braunr> i wanted something that would remain correct for the 64-bit port - -[[64-bit_port]], [[mig_portable_rpc_declarations]]. - - <youpi> ah, you mean because tv_nsec is a long, which will not be the same - type? - <braunr> and tv_sec being a time_t (thus a long too) - <youpi> but we have the same issue e.g. for the rusage structure, don't we? - <braunr> yes - <youpi> so we'll have to fix things for that too anyway - <braunr> sure - <youpi> making a special case will not necessarily help - <braunr> but it doesn't mean new interfaces have to be buggy too - <youpi> well, using the proper type in the server itself is nicer - <youpi> instead of having to convert - <braunr> yes - <braunr> i'm not exactly sure where to declare struct timespec then - <braunr> should it be declared in hurd_types.h, and simply reused by the - libc headers ? - <youpi> ? AIUI, it's the converse, hurd_types.h uses the struct timespec - from libc headers, and defines timespec_t - <braunr> ok - <youpi> timespec_t being the internal type whose definition gets done right - for mig to do the right thing - <braunr> yes - <braunr> i see - <braunr> so, you'd like a struct of integer_t instead of an array of - signed64 - <youpi> for our current 32bit userland yes - <braunr> do you want to make the changes yourself or should i add a new - branch ? - <youpi> and we'll make that a 64bit struct when we have a64bit userland - - -# IRC, freenode, #hurd, 2013-04-06 - - <tschwinge> pinotree: You had once been working on adding nsec-procision - timestamps to GNU Mach's maptime interface (or what the name is). Is - that blocked on something or just waiting to be continued? - <pinotree> blocked on me needing to learn more the proper way to do - "atomic" update of the struct with time :) - - -# IRC, freenode, #hurd, 2013-09-04 - - <teythoon> do we have CLOCK_MONOTONIC ? - <braunr> teythoon: i think we do but it's actually a simple offset from - CLOCK_REALTIME .. :) - <teythoon> ah never mind, I do hate this posix time interface anyways - <braunr> really ? - <braunr> i think librt is decent - - -# Candidate for [[vDSO]] code? - - -# IRC, freenode, #hurd, 2014-02-23 - - <desrt> GLib (gthread-posix.c): Unexpected error from C library during - 'pthread_condattr_setclock': Invalid argument. Aborting. - <desrt> uh oh... - <desrt> time to go digging in glibc i guess... - <braunr> what are you trying to run ? - <desrt> glib - <braunr> with what ? - <desrt> just running glib's test suite under jhbuild - <desrt> i maintain glib and i made some changes recently -- i wanted to - make sure they didn't break the hurd - <desrt> and it seems they have ;/ - <braunr> well - <braunr> the hurd doesn't completely comply with posix 2008 - <desrt> long story short: we've keyed our timed waits on condition - variables to the monotonic clock for a long time now, but we never tested - that it actually worked - <desrt> so i just added an assert -- and indeed it fails on hurd - <braunr> our glibc lies about supporting timers - <braunr> good thinking - <braunr> we don't support the monotonic clock - <desrt> clock_gettime(CLOCK_MONOTONIC) seems to work - <braunr> and you should know that, even if clock selection and timers are - available (which posix 2008 requires), it's still optional - <braunr> no, glibc lies - <desrt> !! - <braunr> our "support" is a mere hack shifting CLOCK_REALTIME - <desrt> it should at least lie consistently :) - <braunr> we need to implement CLOCK_MONOTONIC properly - <desrt> ya... that would be very nice indeed - <braunr> not that hard either - <desrt> i agree! - <braunr> we just have to do it right - <desrt> fwiw, i plan to keep this assert in glib - <braunr> yes, it's good - <desrt> is there anywhere i can file a bug to give you guys some advance - warning? - <braunr> i don't think it's needed - <braunr> we know the problem - <desrt> k -- consider yourself warned, then :) - <braunr> and it's been a bigger concern recently - <desrt> awesome. glad i don't have to do anything :) - <braunr> if it's not already done, i suggest you check for the - CLOCK_MONOTONIC option - <desrt> fwiw, i'm trying to get a regular debian/gnu/hurd build of - glib/gtk/etc setup - <braunr> regular ? - <desrt> ya... out of git master on a daily basis - <braunr> from sources ? - <braunr> oh nice - <desrt> we recently set this up for freebsd as well - <braunr> few maintainers take the pain :) - <desrt> our non-linux 'problem discovery' is a bit crap before now :/ - <braunr> i guess that's pretty normal - <braunr> i don't consider it the responsibility of the maintainers to test - every possible platform - <desrt> glib is a bit unique -- portability is our business - <braunr> taking our patches into consideration is what we ask most - <braunr> right - <desrt> and the "please take the patches" thing is something we want to - stop doing - <braunr> why ? - <desrt> mostly because we often look at a patch that someone sent a few - years ago and say "do we even still need this?" - <desrt> and have no way to know - <braunr> uh - <desrt> you would not believe how many patches like this we've - accumulated... - <braunr> but if we send it now ? :) - <desrt> braunr: new policy is roughly this: - https://wiki.gnome.org/Projects/GLib/SupportedPlatforms - <desrt> ie: fixes for issues that are general portability improvements and - POSIX compliance are welcome... - <desrt> patches that introduce platform-specific #ifdef sections are - rejected unless we have a regular builder to test that code - <braunr> i see - <braunr> again, regarding portability, don't consider CLOCK_MONOTONIC to be - readily available, check for it - <braunr> an #error would be enough but it has to be checked - <desrt> it basically comes down to: we don't want to have code in our - version control that we have no possible way of testing - <braunr> yes - <desrt> braunr: we do check for it - <braunr> ok - <desrt> we assert() if clock_gettime(CLOCK_MONOTONIC) fails - <braunr> no i mean - <desrt> as POSIX said it should if CLOCK_MONOTONIC is not supported - <desrt> if you lie to us.... well, not much we can do - <braunr> POSIX_MONOTONIC_CLOCK - <braunr> _POSIX_MONOTONIC_CLOCK - <desrt> this is actually defined to 0 on most platforms... - <desrt> which does not mean that it's unsupported -- it means that the - runtime must be ready to deal with it not actually existing at runtime - <braunr> really ? - <desrt> yes - <desrt> we used to rely on this and got a bug that we were doing it wrong - :) - <desrt> and indeed, even on linux, both with glibc and uclibc: - <desrt> /usr/include/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK - 0 - <desrt> /usr/include/uClibc/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK - 0 - <braunr> ok it's described in 2.1.6 Options - <braunr> so your check is appropriate - <desrt> so does clock_gettime(MONOTONIC) on debian/hurd get me realtime? - <braunr> either that, or a value shifted from it - <desrt> if so, i'll just hack out the condattr_setclock() check and proceed - trying to build past glib... - * desrt checks - <desrt> as it is, even the build of glib fails since we use some tools - linked against ourselves during the build process... - <desrt> 1393124084790000 1393124084790000 - <desrt> those look the same.... - <braunr> heh - <desrt> i also notice that your clocks are not very high precision :) - <braunr> that's right - <desrt> HZ = 100, i guess - <braunr> yes - <desrt> fair enough - <desrt> our mainloop doesn't support better-than-millisecond accuracy yet - anyway :) - <desrt> (although it will soon...) - <braunr> nice - - -## IRC, freenode, #hurd, 2014-03-05 - - <desrt> braunr: bit of a warning: i released the glib that depends on - working pthread_condattr_setclock(..._MONOTONIC) and pochu said that it - will be landing in debian within the next days - <braunr> desrt: ok diff --git a/open_issues/mach-defpager_swap.mdwn b/open_issues/mach-defpager_swap.mdwn index 6e4dc088..78290d71 100644 --- a/open_issues/mach-defpager_swap.mdwn +++ b/open_issues/mach-defpager_swap.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012,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 @@ -13,6 +13,22 @@ License|/fdl]]."]]"""]] [[!toc]] +# Out of memory situations + +GNU Mach currently does not know how much room mach-defpager has. When it is +full, mach-defpager will start not being able to write data and thus just +lose it. The corresponding object will trigger SIGBUS on access to lost data +(hopefully killing the corresponding process, thus releasing memory). + +GNU Mach should be aware of how much is left, to better manage paging out, +possibly throttling some processes. Hopefully ext2fs will be able to page out +dirty data and release memory. With overcommit control we can then avoid one +process filling the whole memory+swap with anonymous data. If several processes +cooperate in sucking memory, we'd have to OOM some of them. + +E.g. `vm_page_evict` would know not to try to evict an internal page, and just +wait for the external pages to get paged out and get released. + # IRC, OFTC, #debian-hurd, 2012-06-16 <lifeng> I allocated a 5GB partition as swap, but hurd only found 1GB diff --git a/open_issues/nanosecond-precision_clock.mdwn b/open_issues/nanosecond-precision_clock.mdwn new file mode 100644 index 00000000..65690e96 --- /dev/null +++ b/open_issues/nanosecond-precision_clock.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2011, 2013, 2014, 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]]."]]"""]] + +[[!meta title="a nanosecond-precision clock"]] + +[[!tag open_issue_glibc open_issue_gnumach]] + +What about adding a nanosecond-precision clock, too? --[[tschwinge]] + +The y2038 64b interfaces and the mapped time already support it, but the +granularity is still the clock tick period. + +# Candidate for [[vDSO]] code? + 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/serverbootv2.mdwn b/open_issues/serverbootv2.mdwn index 60507fab..21a2f3ec 100644 --- a/open_issues/serverbootv2.mdwn +++ b/open_issues/serverbootv2.mdwn @@ -225,10 +225,8 @@ pci-arbiter. `rumpdisk` exposes `/dev/rumpdisk`: -``` -$ showtrans /dev/rumpdisk - /hurd/rumpdisk -``` + $ showtrans /dev/rumpdisk + /hurd/rumpdisk # FAQ diff --git a/open_issues/smp.mdwn b/open_issues/smp.mdwn index 0be706e3..9820f561 100644 --- a/open_issues/smp.mdwn +++ b/open_issues/smp.mdwn @@ -69,10 +69,8 @@ and add `console=com0` update `/etc/fstab` and update `wd0` instead of `hd0`. -``` -/dev/wd0s2 / ext2 defaults 0 1 -/dev/wd0s1 none swap sw 0 0 -``` + /dev/wd0s2 / ext2 defaults 0 1 + /dev/wd0s1 none swap sw 0 0 You can shutdown via `/sbin/poweroff`. 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/sidebar.mdwn b/sidebar.mdwn index b2c7c223..87b0633b 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -18,6 +18,7 @@ License|/fdl]]."]]"""]] * [[Contact_Us]] * **[[Donate]]** * **[[Contributing]]** + * [[Source Code|source_repositories]] * [[Public_Hurd_Boxen]] * [[QEMU Images|hurd/running/qemu]] * [[Getting Help]] 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/topgit.mdwn b/topgit.mdwn index b27aa09c..3f192482 100644 --- a/topgit.mdwn +++ b/topgit.mdwn @@ -27,6 +27,41 @@ We're using this for some packages, where we're maintaining long-lived development branches, for example [[source_repositories/glibc]]. The latter one has usage examples, too. +# Installing + +It's fairly easy to install topgit. + +You can simply installing from your distribution. + +Alternatively, you can install it from source. + +First, clone the git repo of topgit. + + $ git clone https://repo.or.cz/topgit.git + $ cd topgit + +Or download the tarball of source code directly and unpack it. + + $ curl -o topgit.tar.gz https://repo.or.cz/topgit.git/snapshot/f2815f4debdb07f86ee86dd4eb75280919ace55d.tar.gz + $ tar xzf topgit.tar.gz + $ cd topgit-f2815f4 + +Second, you have to build and install topgit with make. You can use +any prefix to specify the install place. But note that, if you +don't set `prefix`, it will default to `$HOME` rather than `$HOME/.local`, +which may NOT be what you want. + + $ make prefix=$HOME/.local install + +The topgit executable file is `tg`. It will be installed into `$prefix/bin`. + +Finally, add `$prefix/bin` to your `PATH` if you want to use `tg` directly in +your shell. Then test the installation by running `tg` and check the output. + + $ tg + TopGit v0.9 - A different patch queue manager + Usage: tg [...] + # Running it on GNU/Hurd 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> |