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

[Joshua Branson]

Almudena Garcia <liberamenso10000@gmail.com> writes:

> Btw, the Damien's SMP work is based in the mine. He patched my
> previous code which i have stored in my GitHub repository.

I will make a quick edit to note that.

> El domingo 14 de enero de 2024, jbranso@dismail.de escribió:
>> 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
>> +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 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
>> +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]].
>> +
>> +"""]]
>> -- 
>> 2.43.0
>> 
>> 
>>

-- 

Joshua Branson
Sent from the Hurd