news/2023-q3.mdwn: new file.

New qoth file.  Rust port, SMP work, 64-bit port, mmap work, etc.

I added some comments mention that Damien's SMP work is based on
Almudena previous work.  Thanks for than Almudena!
Message-ID: <20240115011642.3201-1-jbranso@dismail.de>

1 files changed, 193 insertions, 0 deletions

diff --git a/news/2023-q3.mdwn b/news/2023-q3.mdwn
new file mode 100644
index 00000000..8050ce98
--- /dev/null
+++ b/news/2023-q3.mdwn
@@ -0,0 +1,193 @@
+[[!meta copyright="Copyright © 2013 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 date="2024-01-01 22:22 UTC"]]
+
+Hello!  Welcome to a new qoth.  This qoth covers new and interesting GNU/Hurd
+developments in Q3 of 2023!
+[[!if test="included()" then="""[[!toggle id=full_news
+text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]"""
+else="
+[[!paste id=full_news]]"]]
+
+[[!cut id="full_news" text="""
+
+Joan Lledo modified the PCI arbiter to prevent mapping I/O region
+files.  He previously sent some patches to implement mapping region
+and ROM files using `mmap()`. However, a `BAR` region can represent
+either memory or I/O space, and only memory should be allowed to be
+mapped.  Since I/O `BARs` only contain I/O addresses, he went ahead
+and [[prevented the mapping of I/O region
+files|https://lists.gnu.org/archive/html/bug-hurd/2023-07/msg00041.html]]. The
+next step is to make IO spaces available for users through the
+pci-arbiter. He plans to add a new RPC that checks for permission and
+calls `i386_io_perm_create()`. Then it returns the resulting port.
+
+Our Google summer of code student Vedant Tewari decided to port rust,
+and the rust porting effort is making good progress.  [[The build
+process is a bit
+wonky|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00091.html]],
+and we are using an older rust version.  Check out [[the rust pull
+request|https://github.com/rust-lang/rust/pull/115230]] that adds Hurd
+support!
+
+[[Samuel|samuelthibault]] worked on setting up
+[[PAE|https://en.wikipedia.org/wiki/Physical_Address_Extension]],
+which will eventually let us use more than 4GB of RAM on a 32-bit
+Hurd!  It is also useful for the X86_64 architecture. He also the
+[[jemalloc|https://lists.debian.org/debian-hurd/2023/08/msg00000.html]]
+build.
+
+Samuel was incredibly productive this quarter making the `X86_64` bit
+port more stable.  He fixed the 64-bit Hurd [[
+PIE|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00040.html]]
+build, and he got [[git
+working|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00059.html]]
+on the 64-bit port!  Though a few of the [[git
+tests|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00069.html]]
+are failing on both `X86_64` and the 32 bit port. He fixed the [[glibc
+build|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00064.html]],
+which involved fixing `pmap_remove` and `pmap_protect`. He discovered
+that [[core dumping is currently causing
+problems|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00068.html]]
+on the 64-bit port, and he temporarily encourages people to disable
+core dumping. Samuel fixed some [[networking
+issues|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00027.html]]
+and a [[dpkg
+issue|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00058.html]]
+for the 64-bit port.  It was hard to discover what the problem was,
+because the debugging tools have not been ported to the 64-bit port.
+He used some locking to fix some bugs, and he encourages other
+developers to help him fix the debugging tools for X86-64. It seems
+that most developers are currently running the 64-bit Hurd in a
+virtual machine and not in real hardware.
+
+Luca Dariz got a patch series merged
+[[for|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00000.html]]
+[[the|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00001.html]]
+[[64|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00002.html]]
+[[bit|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00003.html]]
+[[port|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00004.html]].
+
+Sergey implemented
+[[MAP_EXCL|https://lists.gnu.org/archive/html/bug-hurd/2023-07/msg00010.html]]
+and provided `MAP_FIXED_NOREPLACE` and `MAP_TRYFIXED` as aliases of
+`(MAP_FIXED|MAP_EXCL)` as well other `mmap` work.  He explains:
+
+> `MAP_FIXED` is defined to silently replace any existing mappings at
+> the address range being mapped over. However, this is dangerous and
+> only rarely desired behavior.
+> 
+> Various Unix systems provide replacements or additions to `MAP_FIXED`.
+>
+> * SerenityOS and Linux provide `MAP_FIXED_NOREPLACE`. If the address space
+>   already contains a mapping in the requested range, Linux returns
+>   `EEXIST`. SerenityOS returns `ENOMEM`, however that is a bug, as the
+>   `MAP_FIXED_NOREPLACE` implementation is intended to be compatible with
+>   Linux.
+> 
+> * DragonFly BSD, NetBSD, and OpenBSD provide `MAP_TRYFIXED`, but with
+>   different semantics. DragonFly BSD returns `ENOMEM` if the requested
+>   range already contains existing mappings. NetBSD does not return an
+>   error, but instead creates the mapping at a different address if the
+>   requested range contains mappings. OpenBSD behaves the same, but also
+>   notes that this is the default behavior even without `MAP_TRYFIXED`
+>   (which is the case on the Hurd too).
+> 
+> Since the Hurd leans closer to the BSD side, add `MAP_EXCL` as the
+> primary API to request the behavior of not replacing existing
+> mappings. Declare `MAP_FIXED_NOREPLACE` and `MAP_TRYFIXED` as
+> aliases of `(MAP_FIXED|MAP_EXCL)`, so any existing software that
+> checks for either of those macros will pick them up
+> automatically. For compatibility with Linux, return `EEXIST` if a
+> mapping already exists.
+
+Damien Zammit added a USB mass storage translator via
+[[rumpusbdisk|https://lists.gnu.org/archive/html/bug-hurd/2023-07/msg00025.html]].
+Though it has some issues as he explains:
+
+> Netdde sneems to exhibit a bug when running `ifdown /dev/eth0`
+> simultanously to running the rumpusbdisk translator, because to the
+> two devices share the same IRQ.
+
+Damien also worked on the Hurd's SMP support (much of his SMP
+contributions is based on the earlier work done by Almudena Garcia):
+
+* He tweaked [[GNU Mach's
+scheduler|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00084.html]],
+and he merged [[three|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00080.html]] [[GNU Mach|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00010.html]] [[commits|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00018.html]].
+
+* He added a [[show all
+runqs|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00072.html]]
+command to GNU Mach's kernel debugger.
+
+* He also [[improved SMP in GNU
+Mach|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00048.html]]
+by storing the struct processor in a percpu area and avoiding an
+expensive `cpu_number` every call of `current_processor()`, as well as
+getting the cpu_number from an offset in the percpu area.  Further
+improvements can be made by using other percpu areas. It was untested
+on 64 bit.
+
+* Damien also taught GNU Mach to use the x86 CPUID instruction to get
+the [[CPU
+ID|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00056.html]]
+for speed.  He reduced the time it takes to get the CPUID. He made it
+100 times faster!
+
+* He mentioned
+[[some|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00075.html]] [[issues|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00046.html]]:
+60% of the time, booting a 32 bit Hurd, with SMP enabled, fails to
+boot (sometimes apparently getting stuck in the rumpdisk). When it
+does boot, it is not particularly stable and likely to crash. 
+
+Essentially, the SMP work is progressing, but it is not ready for
+production use. His recent work made the non-SMP faster, and a 32 bit
+Hurd, with SMP enabled and only one core, [[appears relatively stable
+(but slow to
+boot)|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00046.html]].
+The [[32-bit SMP enabled Hurd may soon be as fast as the non-SMP
+Hurd|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00074.html]].
+Eventually the SMP enabled Hurd will be faster than a non-SMP Hurd.
+
+Flavio Cruz halved the size of `mach_msg_type_long_t`, from 16 to 8
+bytes.  He also [[simplified the overall 64bit RPC
+ABI|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00049.html]],
+removing "holes" in `mach_msg_type_t` or `mach_msg_type_long_t`, which
+prevents possible leakages to userspace.
+
+Some Hurd people talked to Kent Overstreet, the author of
+[[bcachefs|https://bcachefs.org/]] to discuss the possibility of
+porting Linux's newest filesystem to the Hurd; the conversation [[was
+recorded|https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00073.html]].
+While most Hurd developers believe that it would possible to port
+bcachefs to the Hurd, all agree that it would be difficult to port and
+hard to maintain.  No Hurd developers are currently planning or
+working on porting bcachefs to the Hurd.  But perhaps you want to?
+
+So if you want to test if your favorite packages work on the Hurd and
+contribute towards making the full GNU system usable for a wider range
+of people, please [[check the contributing page|contributing]].
+
+---
+
+The **GNU Hurd** is the GNU project's replacement for the Unix kernel.  It is a
+collection of servers that run on the Mach microkernel to implement file
+systems, network protocols, file access control, and other features that are
+implemented by the Unix kernel or similar kernels (such as Linux).  [[More
+detailed|hurd/documentation]].
+
+**GNU Mach** is the microkernel upon which a GNU Hurd system is based.  It
+provides an Inter Process Communication (IPC) mechanism that the Hurd uses to
+define interfaces for implementing in a distributed multi-server fashion the
+services a traditional operating system kernel provides.  [[More
+detailed|microkernel/mach/gnumach]].
+
+"""]]