Hi: I'm developing a Rust version of trivfs. It's currently in very early WIP, porting most trivfs functions to Rust, although we get some results making works some translators in Rust. https://gitlab.com/AlmuHS/hurd-translator-in-rust
You can add it to the Qoth if you want. Thanks!! El mié, 1 jul 2026 a las 22:58, Bradley Morgan (<[email protected]>) escribió: > 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! > >
