[Top][All Lists]

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

[PATCH] 2024 q1 qoth file.

From: Joshua Branson
Subject: [PATCH] 2024 q1 qoth file.
Date: Fri, 5 Apr 2024 23:47:56 -0400

* news/2024-q1.mdwn: new qoth file. SMP work, AArch port, etc.
 news/2024-q1.mdwn | 210 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 210 insertions(+)
 create mode 100644 news/2024-q1.mdwn

diff --git a/news/2024-q1.mdwn b/news/2024-q1.mdwn
new file mode 100644
index 00000000..b7df4dba
--- /dev/null
+++ b/news/2024-q1.mdwn
@@ -0,0 +1,210 @@
+[[!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-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]]"]]"""
+[[!paste id=full_news]]"]]
+[[!cut id="full_news" text="""
+Etienne Brateau modified console-client to use [xkbcommon instead of x11 for 
+which actually improves keyboard layout coverage a lot!
+Flavio Cruz also worked on [porting GDB to the 64-bit
+implemented `setcontext/getcontext/makecontext/swapcontex ()` in
+[glibc](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00106.html), and
+he[ implemented child process resource
+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 
+also posted a [RFC to enhance tracing
+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-03/msg00008.html), and
+Damien Zammit had some fixes including [fixing the console with APIC
+[patching GNU Mach to support ACPI
+v2](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00278.html), [fixing
+baud rate on com
+[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
+Damien also worked on more SMP fixes
+[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). He
+also wrote a test program that lets you run a [task via
+Sergey Bugaev [patched binutils to support the GNU/Hurd on
+he wrote some patches to make the Hurd easier to port
+[here](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00063.html), and
+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
+    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
+In Sergey's later glibc patch series, he wrote about the [AArch64 port
+    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 
+     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 
+     proof-of-concept state rather than being seriously production-ready; and 
+     that Mach is a small kernel (indeed, a microkernel), and it was designed 
+     the start (back in the 80s) to be portable, so most of the "buisness 
+     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
+Sergey also announced [a new GNU/Hurd based distro based on Alpine
+Linux](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 
+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. Sergey is probably the only person using it, but if you are 
+in helping him develop it further, then please email bug-hurd@gnu.org.
+Luca Dariz added [userspace
+work with qemu. We currently test the Hurd via a GNU/Linux host running 
+on qemu. He also described how [he currently uses the 64-bit
+Perhaps you should follow that advice if you want to try running a 64-bit Hurd
+on qemu.
+Manolo de Medici got a not-yet-complete patch series that gets [qemu
+to run on the
+Hurd](https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00153.html). If
+you feel daring, then you could compile and run qemu with his patches,
+and we should probably polish the patches for upstream inclusion.
+I (badly?) 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
+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

base-commit: 45c29e1104089fe61bc04d6fd68b4b415dfccfc3

reply via email to

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