On July 1, 2026 9:52:00 PM GMT+01:00, Joshua Branson <[email protected]> wrote: >--- > 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. >+ > I search my name, I see my name, I get made happy
(btw include is me!) Also, please take Acked-by: Bradley Morgan <[email protected]> (No idea if we do this jazz, oh well) Thanks!
