Tux Machines
Posted by Roy Schestowitz on Apr 20, 2023
=> Raspberry Pi, Arduino, and More | Security Leftovers
My name is Lars Wirzenius, and I was there when Linux started. Linux is now a global success, but its beginnings were rather more humble. These are my memories of the earliest days of Linux, its creation, and the start of its path to where it is today.
I started my computer science studies at the University of Helsinki in the fall of 1988, and met Linus Torvalds, who was the other new Swedish speaking student in computer science that year. Toward the end of that first year, we had gotten access to a Unix server, and I accidentally found Usenet, the discussion system, by mistyping rm as rn, the Usenet reader. I told Linus about it and we spent way too much time exploring this.
After the first year, we both went away to do the mandatory military service, though in different places. We returned to our university studies in the fall of 1990, and both took the course on C and Unix programming, which included a fair bit of theory of the Unix kernel architecture as well. This led to us reading about other operating system kernels, such as QNX and Plan 9. Linus and I discussed with some enthusiasm how an operating system should be built correctly. We had all the overconfidence of 20-year-old second-year university students. Everyone is better off that this wasn't recorded for posterity.
In January 1991, Linus bought his first PC from a local shop that assembled computers from parts. The PC had a 386 CPU, which was relatively fancy at that time, because Linus wanted to explore multitasking. Also, since he came from a Sinclair QL with a 32-bit Motorola 68008 CPU, he wanted a 32-bit CPU, and did not want to step down to a 16-bit one, so a 286 was not an option. Linus's first PC had a whopping 4 megabytes of RAM and a hard drive.
He got a copy of the game Prince of Persia, which occupied most of his spare time for the next couple of months. He later also bought a copy of MINIX, because after using Unix at the university, he wanted something like that at home as well.
=> ↺ Seeking an acceptable unaccepted memory policy
Operating systems have traditionally used all of the memory that the hardware provides to them. The advent of virtualization and confidential computing is changing this picture somewhat, though; the system can now be more picky about which memory it will use. Patches to add support for explicit memory acceptance when running under AMD's Secure Encrypted Virtualization and Secure Nested Paging (SEV-SNP), though, have run into some turbulence over how to handle a backward-compatibility issue.
Normally, when the operating-system kernel boots, it discovers the available memory and happily sets itself up to use that memory. Version 2.9 of the UEFI specification, though, added the concept of unaccepted memory; when this mechanism is in use, a system (normally a virtualized guest) will be launched with its memory in an unaccepted state. That system will not be able to make use of the memory provided until that memory has been explicitly accepted. On such systems, the bootloader will typically pre-accept enough memory to allow the guest kernel to boot; that kernel must take responsibility for accepting the rest before using it.
=> ↺ The shrinking role of semaphores
The kernel's handling of concurrency has changed a lot over the years. In 2023, a kernel developer's toolkit includes tools like completions, highly optimized mutexes, and a variety of lockless algorithms. But, once upon a time, concurrency control came down to the use of simple semaphores; a discussion on a small change to the semaphore API shows just how much the role of semaphores has changed over the course of the kernel's history.
At its core, a semaphore is an integer counter used to control access to a resource. Code needing access must first decrement the counter — but only if the counter's value is greater than zero; otherwise it must wait for the value to increase. Releasing the semaphore is a matter of incrementing the counter. In the Linux kernel implementation, acquisition of a semaphore happens with a call to down() (or one of a few variants); if the semaphore is unavailable, down() will wait until some other thread releases it. The release operation, unsurprisingly, is called up(). In the classic literature, as defined by Edsger Dijkstra, those operations are called P() and V() instead.
The extended BPF (eBPF) virtual machine allows programs to be loaded into and executed with the kernel — and, increasingly, other environments. As the use of BPF grows, so does interest in defining what the BPF virtual machine actually is. In an effort to ensure a consistent and fair environment for defining what constitutes the official BPF language and run-time environment, and to encourage NVMe vendors to support BPF offloading, a recent effort has been undertaken to standardize BPF.
BPF programs are written in C, and compiled into BPF bytecode. Like other bytecode instruction sets, BPF programs are platform-independent and just-in-time (JIT) compiled. For a long time, "platform-independent" for BPF simply meant the ability to run BPF programs on multiple different architectures on Linux. That definition has expanded in recent years, with Microsoft implementing a version of BPF for Windows, and network-interface vendors, such as Netronome, providing the ability to offload BPF networking programs. NVMe vendors are also looking into supporting offloading functionality to BPF for storage devices with a new framework called eXpress Resubmission Path (XRP), though this effort is currently stalled due to BPF not being standardized.
The Linux Foundation (LF), the nonprofit organization enabling mass innovation through open source, today announced the incorporation of the Open Compute Switch Abstraction Interface (SAI) into the open source DENT Network Operating System (NOS) project. This move marks a milestone in the collaboration between the Linux Foundation and the Open Compute Project (OCP), aimed at benefiting the entire open-source community by providing a unified and standardized approach to networking across hardware and software.
=> gemini.tuxmachines.org This content has been proxied by September (ba2dc).Proxy Information
text/gemini;lang=en-GB