Btw, the Damien's SMP work is based in the mine. He patched my previous code which i have stored in my GitHub repository.
El domingo 14 de enero de 2024, jbra...@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 > > > -- Enviado desde mi dispositivo Sailfish
