Re: [PATCH] 2024 q1 qoth file.

[Samuel Thibault]

published, thanks!

Nathan Dehnel, le dim. 07 avril 2024 03:38:04 -0500, a ecrit:
> I made edits to your patch.

> From 7c8852217dfcee0a8623320afd3d96be7abcfb51 Mon Sep 17 00:00:00 2001
> From: Nathan Dehnel <5498361+Gooberpatrol66@users.noreply.github.com>
> Date: Sun, 7 Apr 2024 03:26:39 -0500
> Subject: [PATCH] 2024-q1.mdwm
> 
> ---
>  news/2024-q1.mdwm | 203 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 203 insertions(+)
>  create mode 100644 news/2024-q1.mdwm
> 
> diff --git a/news/2024-q1.mdwm b/news/2024-q1.mdwm
> new file mode 100644
> index 00000000..d52c3b9d
> --- /dev/null
> +++ b/news/2024-q1.mdwm
> @@ -0,0 +1,203 @@
> +[[!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-04-05 11:07 UTC"]]
> +
> +Hello!  Welcome to a new qoth.  This qoth covers new and interesting GNU/Hurd
> +developments in Q1 of 2024!
> +[[!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="""
> +
> +Etienne Brateau modified console-client to use [xkbcommon instead of x11 for 
> xkb
> +extended
> +support](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00060.html),
> +which improves keyboard layout coverage a lot!
> +
> +Flavio Cruz also worked on [porting GDB to the 64-bit
> +Hurd](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00147.html),
> +implemented `setcontext/getcontext/makecontext/swapcontex ()` in
> +[glibc](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00106.html), 
> and [implemented child process resource
> +accounting](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00098.html).
> +The latter implements`getrusage(RUSAGE_CHILDREN, )` and populates child 
> related
> +data in `times()`.
> +
> +He fixed the [perl testsuite for the
> +Hurd](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00021.html), 
> and he
> +also posted a [RFC to enhance tracing
> +utilities](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00034.html),
> +which he used to port the RPC format to 64 bit.
> +
> +Flavio also had a smattering of fixes
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00219.html),
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00091.html),
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00151.html),
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00008.html), 
> and
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00068.html).
> +
> +Damien Zammit had some fixes including [fixing the console with APIC
> +enabled](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00277.html),
> +[patching GNU Mach to support ACPI
> +v2](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00278.html), 
> [fixing
> +baud rate on com
> +ports](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00176.html),
> +[porting the Hurd to some AMD
> +CPUs](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00220.html) 
> (WIP),
> +[adding HPET (high precision
> +timers)](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00039.html). 
> He
> +also worked on making `ext2fs` [use xattr by default to store
> +translators](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00012.html).
> +
> +Damien also worked on more SMP fixes
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00016.html),
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00021.html),
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00051.html),
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00063.html),
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00079.html), 
> and
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00124.html). 
> +Hurd currently boots in SMP mode on the BSP. Damien wrote a test program 
> that lets you run a [task on the 
> APs](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html).
> +
> +Sergey Bugaev [patched binutils to support the GNU/Hurd on
> +AArch64](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00000.html), 
> and
> +he wrote some patches to make the Hurd easier to port
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00002.html),
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00063.html), 
> and
> +[here](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00100.html),
> +
> +Sergey also posted a fairly large [RFC patch series for his AArch64
> +port](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00022.html). He
> +writes:
> +
> +    MIG seems to just work (thanks to all of Flávio's work!). I'm using
> +     the same message ABI as on x86_64, and haven't seen any issues so far
> +     — neither compiler errors / failed static assertions (about struct
> +     sizes and such), nor hardware errors from misaligned accesses.
> +
> +
> +He also mentions that "the hardware hardening features (BTI, MTE, PAC) are
> +currently 'not really supported', but I do want to support them in the 
> future."
> +Samuel merged
> +[many](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00050.html)
> +[of](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00051.html)
> +[the](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00052.html)
> +[patches](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00062.html).
> +
> +In Sergey's later glibc patch series, he wrote about the [AArch64 port
> +progress](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00114.html).
>  He
> +wrote:
> +
> +    Last time, there was no AArch64 port of GNU Mach, and so the only testing
> +     I have done was running a simple statically-linked executable on Linux 
> under
> +     GDB, which, nevertheless, helped me identify and fix a number of issues.
> +
> +     Since then, however, I have been (some may say, relentlessly) working on
> +     filling in the missing piece, namely porting GNU Mach (with important 
> help &
> +     contributions by Luca D.). I am happy to report that we now have an
> +     experimental port of GNU Mach that builds and works on AArch64! While 
> that may
> +     sound impressive, note that various things about it are in an extremely 
> basic,
> +     proof-of-concept state rather than being seriously production-ready; 
> and also
> +     that Mach is a small kernel (indeed, a microkernel), and it was 
> designed from
> +     the start (back in the 80s) to be portable, so most of the "buisness 
> logic"
> +     functionality (virtual memory, IPC, tasks/threads/scheduler) is 
> explicitly
> +     arch-independent.
> +
> +     Despite the scary "WIP proof-of-concept" status, there is enough
> +     functionality in Mach to run userland code, handle exceptions and
> +     syscalls, interact with the MMU to implement all the expected virtual
> +     memory semantics, schedule/switch tasks and threads, and so on.
> +     Moreover, all of GNU Mach's userspace self-tests pass!
> +
> +     This meant there was enough things in place for me to try running
> +     glibc on it, and the amazing thing is my simple test executable, the
> +     same one I previously tested on Linux with GDB, just worked on real
> +     Mach without me having to make any additional changes to the glibc
> +     side, or even recompile it.
> +
> +     But I did not stop there, and I got several of the core Hurd servers
> +     working!  Namely, these are ext2fs, exec, startup, auth, and proc
> +     servers. All of them but ext2fs are dynamically linked; ld
> +     aarch64.so.1 sucessfully locates and maps the programs themselves
> +     and their required dependencies, and Mach pages in code and data
> +     pages from ext2fs as they are accessed, transparently to the
> +     program, just as one would expect it to.
> +
> +
> +Be sure to read more from his announcement
> +[email](https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00114.html).
> +
> +Sergey also announced [a new Alpine distro based on 
> Hurd](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00180.html) (it
> +currently does not have a name). His goal is to add another Hurd 
> distribution,
> +which will force the Hurd to work with different software and hopefully fix 
> more
> +bugs. Alpine Linux also usually runs the latest software, so this new Hurd
> +distribution will be for those who like living on the bleeding edge. He 
> writes:
> +
> +
> +    I have ported many Alpine packages to build with (i386, for now) GNU
> +     Mach, the Hurd, and glibc, replacing Linux and musl. If you want a
> +     specific number: as of yesterday, I have 299 installable packages; the
> +     number of source packages is of course several times less than that.
> +     Still, this includes things like curl, ncurses, nano, native binutils
> +     & gcc & mig, libffi, openrc, openssl, util-linux, busybox, apk-tools,
> +     ... and of course gnumach, hurd (with dependencies like libdaemon,
> +     parted, ...), and glibc. Importantly, all this cleanly bootstraps
> +     using the scripts/bootstrap.sh script that they provide; this is too
> +     somewhat like Flávio's scripts, but it uses the real full Alpine
> +     package definitions for e.g. GCC (patched by me for glibc / Hurd
> +     support).
> +
> +     Above the kernel and libc, things remain much as they were in upstream
> +     Alpine: the system boots (will boot — I haven't tried it yet) with
> +     busybox init & OpenRC, and uses busybox as its basic userland. GNU
> +     software such as Bash is installable, too.
> +
> +
> +This new Hurd distribution currently does not have a mailing list, irc room, 
> or
> +website. If you are interesting
> +in helping Sergei to develop it further, then please email bug-hurd@gnu.org.
> +
> +Luca Dariz added [userspace
> +tests](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00125.html), 
> which
> +work with qemu. We currently test the Hurd in qemu on a GNU/Linux host. He 
> also described how [he currently uses the 64-bit
> +Hurd](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00047.html).
> +Perhaps you should follow that advice if you want to try running a 64-bit 
> Hurd
> +on qemu.
> +
> +Manolo de Medici made a WIP patch series that gets [qemu
> +to run on the
> +Hurd](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00153.html).
> +
> +I organized a belated GNU/Hurd Christmas party. We had 6 or 7
> +attenders, which was pretty awesome! I was not able to record the event, so
> +perhaps we should try for another meet perhaps at the end of Q2. If you would
> +like to help me plan/organize/join such a party, then please email
> +bug-hurd@gnu.org.
> +
> +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.41.0
> 


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