--- news/2026-q2.mdwn | 325 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 325 insertions(+) create mode 100644 news/2026-q2.mdwn
diff --git a/news/2026-q2.mdwn b/news/2026-q2.mdwn new file mode 100644 index 00000000..2fc8ea10 --- /dev/null +++ b/news/2026-q2.mdwn @@ -0,0 +1,325 @@ +[[!meta copyright="Copyright © 2026 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]]."]]"""]] + +<!-- TODO before committing + +These wiki pages need to be added to hurd.gnu.org: + +hurd/translator/9pfs +hurd/translator/eth-multiplexer +logo/ethernet-multiplexor.svg + +--> + +Hello and welcome to another Qoth! Here's what's been happening in Q2 +of 2026! + +Joshua Branson added a pretty cool svg logo for our [[ethernet +multiplexor|hurd/translator/eth-multiplexer]]. He built that image +with a Hurd laptop (Thinkpad 420) running on real iron via Inkscape! +The Hurd wiki could certainly use more artwork. Perhaps you have a +favorite Hurd translator that you believes needs some artwork! + +Sergey Bugaev announced his [WIP +9pfs](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00012.html), +and it has a [[wiki page|hurd/translator/9pfs]]! He writes: + + Some years ago, I experimented with implementing a 9P translator for + the Hurd. Hopefully there is no need to tell this list what 9P is :) + + Besides just browsing files on the few existing servers out there, a + potential use case is virtio-9p, to enable shared directory trees + between VMs and the host. But that would need someone to implement + virtio support in the Hurd. + + I wanted to complete 9pfs before publishing, but that ultimately + didn't happen, so now it's time to turn it over to the community. I + now went and made the repository public on GitHub: + https://github.com/bugaevc/9pfs + + What's implemented is basic browsing (readdir, stat), path resolution + (dir_lookup), and reading files (io_read). And below that, the whole + tracking for nodes, peropens, protids, fids, tags, and 9p RPCs. + + Improvements are welcome, send patches to this list with [PATCH 9pfs] + in the subject. A good starting point would be to continue porting + things that I had implemented in the old netfs-based version (see + netfs.c) but didn't yet port to the new one. + +He then got a little more motivated, and he added some write support! + +Etienne Brateau added +[validation](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00098.html) +to [msync](https://man7.org/linux/man-pages/man2/msync.2.html), so +that the Hurd better follows POSIX. + +Diego Nieto Cid worked on allowing privileged users to set its task +priority (nice value). His patches landed in +[glibc](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00100.html) +and [GNU +Mach](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00099.html). + +He also fixed a [tiny +bug](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00232.html) +in our test suite. He fixed an adjtime bug, which is helpful to [the +OpenNTP +port](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00061.html). +He fixed +[two more](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00133.html) +[bugs](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00117.html). + + +Paulo Duarte sent a RFC patch series trying to commit Sergey’s +previous AArch64 work. He writes: + + This series adds the gnumach kernel-side implementation for the + aarch64 ABI Sergey landed in April 2024, plus the test-suite arms. + Patch 01 brings in the aarch64-only sources from bugaevc/wip-aarch64 + verbatim, with Sergey as Author; the rest is mine. + + The meaningful divergence from wip-aarch64 is what I left out: + roughly 150 files of cross-arch refactoring across kern/, ipc/, vm/, + device/intr.{c,h}, and the i386 tree. Each got replaced with a + smaller per-arch shim under aarch64/ so kern/bootstrap.c, + device/intr.{c,h}, kern/lock.h, and the i386 trees all stay + bit-identical to current master. The shared-file footprint outside + aarch64/ is four files: a new ELF constant, two missing decls plus + their include, and a linker-symbol filter extension... + + Tested: 12/12 pass on x86_64, i686, and aarch64 under qemu. No + bare-metal validation yet. I plan to build bootable images and boot + the kernel on Apple M1 / Raspberry Pi (aarch64) and an x86_64 box + (x86_64 + i686). Help on any of these welcome. + + +He also fixed a [tiny cross compilation issue](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00077.html). + + +gfleury fixed some [tmpfs +typos](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00038.html). +He also fixed a [kernel crash on a null pointer +deference](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00101.html). + +Joan Lledó continued his work [on](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00067.html) [porting](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00146.html) [dhcpcd](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00028.html). + +Mikhail Karpov added some checks for [mmap in several places](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00165.html). + +He also worked on adding storeio to the [bootstrap +chain](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00221.html). +This is actually quite interesting. Currently the Hurd sets device +entries in `/dev/` statically. For example, I am writing this qoth on +a Hurd machine that is using two `/dev/` entries for my filesystem: +`/dev/wd0s1` for swap and `/dev/wd0s5` for my root filesystem. +However, `/dev/wd0s1` through `/dev/wd0s16` exist on my computer! +Once Mikhail's project is done, then the Hurd will dynamically +populate SATA devices at boot time! No more need for static +translators! [He +writes](https://lists.gnu.org/archive/html/bug-hurd/2026-05/msg00041.html): + + + I've expanded the functionality of the partfs translator to work + with multiple disks and their partitions. Thus, by running the + command: + settrans -c partfs /hurd/partfs /root/disk1.img /root/disk2.img /root/disk3.img + + + The translator directory will have the following directory tree: + partfs + ├── 0 + │ ├── 1 + │ ├── 2 + │ └── ... + ├── 1 + │ ├── 1 + │ ├── 2 + │ └── ... + ├── 2 + │ ├── 1 + │ ├── 2 + │ └── ... + Since the disks are directories, the cd and ls commands work in the translator node. + + I also tested mounting, reading, and writing using the commands: + `settrans -c ext01 /hurd/ext2fs -w -T typed file:/root/partfs/0/1` + and + `settrans -c ext1_1 /hurd/ext2fs -w -T typed part:1:file:/root/partfs/1` + + + +It actually is even cooler! Samuel (our fearless leader) is [seeking +feedback](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00187.html) +for how to name these newer `/dev/` entries. Samuel [writes](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00187.html): + + One thing that would be really needed for efficiency is to implement + netfs_file_get_storage_info, so that libstore would be able to get the + underlying storage information, and directly get data from there rather + than partfs having to pass data with io_read/write. + + I'm then wondering how this would fit in the "grand scheme". Our current + approach, /dev/hd0s* being always there, is indeed not really good + because it doesn't easily tell the user which partitions are actually + there. We used to have to have this because partitions used to be + handled by the kernel, and then we have moved to + storerio+parted-supported partitions, which brings much more + flexibility. + + Perhaps we could use + + settrans -c /dev/hd0s /hurd/partfs /dev/hd0 + + and then we'd have /dev/hd0s/1, which is almost like before, but allows + the entries to be dynamic. Actually, we could even have some + + settrans -c /dev/hd /hurd/probedisk hd + + and then we'd have /dev/hd/0, and we could have /dev/hd/0s being partfs, + so we'd eventually have + + /dev/hd/0s/1 + + But I'm also thinking that perhaps it could be integrated more with + storeio, i.e. /dev/hd0 can as well also act as a directory with partfs + behavior, so you could have + + /dev/hd0/1 + + and with the probedisk translator, you could have + + /dev/hd/0/1 + + What do people think about it? + + +The mysterious developer “include” [allowed passing “-s” to +init](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00082.html). +Previously, passing "-s" to init was silently ignored. + + +Mike Kelly has been hard at work [porting OpenBSD’s +OpenNTP](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00185.html). +The Hurd doesn't currently have a openNTP daemon, so thanks Mike! + +He also was debugging a [weird memory error with +rump](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00029.html), +and he provided a ["brown-tape" +solution](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00136.html) +for it. Hopefully, he (or you dear reader), can reach out to the +NetBSD people to fix this bug. This just goes to show that when two +projects use the same code, both projects benefit! + +He also got a [glibc patch +committed](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00012.html). +Essentially `SIGSTOP`/`SIGCONT` was duplicating portions of files, +which is now fixed. However, there are still some [other +issues](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00149.html) +with building some haskell packages. + + + +Bradley Morgan fixed a [tiny implementation bug with +cat](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00120.html). He +also tweaked procfs to [show hidden +files](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00122.html). + +Johannes Schauer Marin Rodrigues has been working on getting [s-build to run on amd64 Hurd](https://lists.debian.org/debian-hurd/2026/06/msg00000.html). + + +Milos Nikic ported +[Neovim](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00141.html). + +He also worked on +[bug](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00179.html) +[fixes](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00195.html) +to +[libdiskfs](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00020.html), +and he fixed a deadlock bug in the [“ext3/ext4” filesystem +journal](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00171.html). + + +In the last qoth we had talked about how the Milos was working on +adding an ext3/ext4 binary compatible journal. Samuel has committed +it! Samuel wrote: + + There is a couple things that I fixed on the fly: + + - We want to use pthread_cond_clockwait rather than + pthread_cond_timedwait, to be able to use CLOCK_MONOTONIC instead of + CLOCK_REALTIME, to avoid being hit by ntpdate and such. + + - In diskfs_S_dir_rename, there was an addition of: + + pthread_mutex_unlock (&fnp->lock); + + which was clearly bogus: we were unlocking it again below. + + There are a couple things that we'd want to fix now: + + - when calling diskfs_file_update, don't we have to be inside a + transaction? Otherwise if we pass wait=1 and use a journal, we won't + be waiting AIUI? Notably, in diskfs_S_dir_rmdir we don't use a + transaction. And ideally we'd have an assertion that makes sure we + respect this. + + - we should define some helper for this recurring pattern: + + if ((docommit) && (diskfs_synchronous || diskfs_journal_needs_sync (txn))) + diskfs_journal_commit_transaction (txn); + else + diskfs_journal_stop_transaction (txn); + + - journal_drain_deferred_blocks should document what it does, not just + its call conditions :), and more generally the functions that are + not already documented in a .h and not just a _locked variant of a + documented function. + +Leonardo Lopes Pereira did some [spring +cleaning](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00083.html) +to remove some [dead +code](https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00084.html). + + + +Samuel Thibault mentioned [in an +email](https://lists.debian.org/debian-hurd/2026/04/msg00016.html) +that the Hurd can support nvmes with rump, but that the work was just +not done yet. Perhaps you, dear reader, would like to help us +accomplish this task? + +The mysterious user yelini worked on [porting the D language compiler](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00069.html). + + +Damien Zammit worked on [tweaking the Hurd’s WIP CI](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00139.html). + +He also +[fixed](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00106.html) +[several](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00100.html) +[bugs](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00117.html) +to make it possible to run the Hurd’s test suite from GNU/Linux +running on an AArch64 computer. + +He also is working on integrating qemu’s Hurd support into [upstream +qemu’s +CI](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00102.html), +so that the support does not bitrot. + + +Sophiel Zhou fixed [a tiny pfinet permission checking +issue](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00027.html) +and taught [pfinet to not fail under memory pressure](https://lists.gnu.org/archive/html/bug-hurd/2026-06/msg00043.html): + + This series fixes two latent crash bugs in pfinet where mmap + return values go unchecked, may causing crash when memory is tight. + + Both bugs follow the same pattern: mmap is called to grow a buffer, + but the returned pointer is dereferenced before (or without) checking + for MAP_FAILED. Under normal operation mmap rarely fails, so these + have gone unnoticed, but under address-space pressure pfinet would + crash. + -- 2.53.0
