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

[Samuel Thibault]

Applied, thanks!

jbranso@dismail.de, le dim. 14 janv. 2024 20:15:58 -0500, a ecrit:
> 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!
> ---
>  news/2023-q3.mdwn | 193 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 193 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..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]].
> +
> +"""]]
> -- 
> 2.43.0
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.