[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] news/2023-q3.mdwn: new file.

From: address@hidden
Subject: [PATCH] news/2023-q3.mdwn: new file.
Date: Sun, 14 Jan 2024 17:41:21 -0500

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

Ya'll were busy q3 of 2023!  Great work everyone!
 news/2023-q3.mdwn | 192 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 192 insertions(+)
 create mode 100644 news/2023-q3.mdwn

diff --git a/news/2023-q3.mdwn b/news/2023-q3.mdwn
new file mode 100644
index 00000000..4d12305c
--- /dev/null
+++ b/news/2023-q3.mdwn
@@ -0,0 +1,192 @@
+[[!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
+[[!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]]"]]"""
+[[!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
+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
+[[Samuel|samuelthibault]] worked on setting up
+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
+Samuel was incredibly productive this quarter making the `X86_64` bit
+port more stable.  He fixed the 64-bit Hurd [[
+build, and he got [[git
+on the 64-bit port!  Though a few of the [[git
+are failing on both `X86_64` and the 32 bit port. He fixed the [[glibc
+which involved fixing `pmap_remove` and `pmap_protect`. He discovered
+that [[core dumping is currently causing
+on the 64-bit port, and he temporarily encourages people to disable
+core dumping. Samuel fixed some [[networking
+and a [[dpkg
+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
+Sergey implemented
+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
+Though it has some issues as he explains:
+> Netdde seems to exhibit a bug when running `ifdown /dev/eth0`
+> simultaneously to running the rumpusbdisk translator, because to the
+> two devices share the same IRQ.
+Damien also worked on the Hurd's SMP support:
+* He tweaked [[GNU Mach's
+and he merged 
[[GNU Mach|https://lists.gnu.org/archive/html/bug-hurd/2023-08/msg00010.html]] 
+* He added a [[show all
+command to GNU Mach's kernel debugger.
+* He also [[improved SMP in GNU
+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
+for speed.  He reduced the time it takes to get the CPUID. He made it
+100 times faster!
+* He mentioned
+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
+The [[32-bit SMP enabled Hurd may soon be as fast as the non-SMP
+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
+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
+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
+**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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]