You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/this-month/2020-09.md
+59Lines changed: 59 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -6,6 +6,7 @@ date = 0000-01-01
6
6
month = "September 2020"
7
7
authors = [
8
8
"phil-opp",
9
+
"IsaacWoods",
9
10
# add yourself here
10
11
]
11
12
+++
@@ -36,6 +37,36 @@ The `x86_64` crate provides various abstractions for `x86_64` systems, including
36
37
37
38
In September, …
38
39
40
+
### [`acpi`](https://github.com/rust-osdev/acpi)
41
+
<spanclass="gray">(Section written by [@IsaacWoods](https://github.com/IsaacWoods))</span>
42
+
The `acpi` repository contains crates for parsing the ACPI tables – data structures that the firmware of modern computers use to relay information about the hardware to the OS. Lots of work happened this month:
43
+
44
+
*[Support](https://github.com/rust-osdev/acpi/pull/76) for the `Fixed Memory`, `Word Address Space`, `DWord Address Space`, `QWord Address Space`, `IRQ Format`,
45
+
`DMA Format`, and `I/O Port Descriptor` resource descriptors were added. These appear in `_CRS` objects - objects
46
+
that describe the resources allocated to a particular hardware device. This should be enough support to parse the
47
+
`_CRS` objects of all devices supported by QEMU. Thanks to [`@michaelmelanson`](https://github.com/michaelmelanson) for his contribution!
48
+
*[Version `2.0.0` of the `acpi` crate was published](https://github.com/rust-osdev/acpi/pull/75), after [consultation with contributors to the Redox project](https://github.com/rust-osdev/acpi/issues/74).
49
+
This splits the library into two parts - discovering ACPI tables using various methods, and separately, parsing them to discover information about the system.
50
+
This provides much more flexibility in how tables are parsed, allows support for OS-specific tables, and is
51
+
important to the Redox project as it allows parsing of the ACPI tables in userspace. We also used this
52
+
opportunity for breaking changes to clean up a few parts of the library, especially in making our method of
53
+
mapping physical memory ranges safer.
54
+
* A new crate, [rsdp](https://crates.io/crates/rsdp), was split out from `acpi`. This new crate provides methods
55
+
for searching for the first ACPI table (the Root System Description Pointer (RSDP)) on BIOS systems without
56
+
`alloc` support. This makes it suitable for use from bootloaders and similar applications where heap allocation
57
+
is not supported. All types are reexported by the `acpi` crate, so users can access the same functionality from
<spanclass="gray">(Section written by [@IsaacWoods](https://github.com/IsaacWoods))</span>
62
+
`pci_types` is a new library in the Rust OSDev organisation that provides types for accessing and configuring PCI
63
+
devices from Rust operating systems. Lots of this code (e.g. identifying devices by class codes) can be shared
64
+
between projects, and would benefit from community contributions. This month, work started on some types for
65
+
representing PCIe addresses, the layout of the configuration space for *endpoints*, device types, and a trait that
66
+
allows the library to access the PCIe configuration space in whichever way the platform exposes it.
67
+
68
+
Thanks to [@toku-sa-n](https://github.com/toku-sa-n) for their [contribution](https://github.com/rust-osdev/pci_types/pull/1)!
69
+
39
70
## Personal Projects
40
71
41
72
In this section, we describe updates to personal projects that are not directly related to the `rust-osdev` organization. Feel free to [create a pull request](https://github.com/rust-osdev/homepage/pulls) with the updates of your OS project for the next post.
@@ -46,6 +77,34 @@ In this section, we describe updates to personal projects that are not directly
<spanclass="gray">(Section written by [@IsaacWoods](https://github.com/IsaacWoods))</span>
82
+
83
+
A fairly large amount of progress has been made on Pebble over the last two months, and a prototype of Pebble's
84
+
defining feature (easy message passing between tasks) is now working!
85
+
86
+
* The first, basic, version of Pebble's wire format, [ptah](https://github.com/IsaacWoods/pebble/tree/master/lib/ptah) has been completed.
87
+
This first version is implemented as a Serde format, but libraries could be written for any language that can
88
+
manipulate a byte stream.
89
+
* Two system calls, `send_message` and `get_message`, were added that allows a message (a series of bytes, and
90
+
optionally a number of *handles* (effectively, permission to access a certain *kernel object*)) to be sent
91
+
down a *channel*, between two tasks.
92
+
* Infrastructure for another of Pebble's key features, *services*, was added. This allows userspace tasks to
93
+
advertise their ability to provide some kind of 'service' to other tasks. A task called [`echo`](https://github.com/IsaacWoods/pebble/blob/master/user/echo/src/main.rs)
94
+
was built to test this - it provides a service that simply echos any messages sent down it back to the sending
95
+
task.
96
+
* Work started on the Platform Bus, a concept inspired by another hobby OS [managarm's `mbus`](https://github.com/managarm/managarm/blob/master/docs/src/design/mbus/index.md).
97
+
All hardware devices on the platform will be added to the Platform Bus by *Bus Drivers*, and described using *properties* (as an
98
+
example, a PCI device will have properties such as `pci.vendor_id`, and `pci.class`). *Device drivers* will be
99
+
able to apply to manage devices by sending a *Filter* to the Platform Bus, which specifies which devices they are
100
+
able to handle, based on a device's properties. In the future, Platform Bus will be reponsible for handling all
101
+
PCI, USB, and hardwired devices on all platforms.
102
+
* The first *Bus Driver* was added to manage PCI devices. It uses a new system call, `pci_get_info`, to get the raw
103
+
information about PCI from the kernel, and then creates a Platform Bus device for each function, with the correct
104
+
properties. It uses the new `pci_types` library in the Rust OSDev organisation to identify each device (in the
105
+
future, this will be extended to know about specific vendor+device ID combinations, to identify specific devices
0 commit comments