Jump to content

Design: Difference between revisions

From postmarketOS Wiki
Created page with "A great deal of postmarketOS's design lies in how we use packaging to create various abstract layers in the OS for supporting devices and user interfaces. This gives users and manufacturers a lot of flexibility to build pmOS images to meet their use cases, and this makes it easy to add support for new devices and user interfaces in the OS without having to worry about creating conflicts with other devices/UIs. = Device Packages = Device support in postmarketOS is handl..."
 
 
Line 24: Line 24:
==== Generic Device Packages ====
==== Generic Device Packages ====


These are a special flavor of device packages packages that provide config for
These are a special flavor of device packages that provide config for
a specific class or family of devices, for example <code>generic-x86_64</code>
a specific class or family of devices, for example <code>generic-x86_64</code>
for supporting general x86_64 computers that are not specific to any
for supporting general x86_64 computers that are not specific to any

Latest revision as of 19:11, 24 May 2024

A great deal of postmarketOS's design lies in how we use packaging to create various abstract layers in the OS for supporting devices and user interfaces. This gives users and manufacturers a lot of flexibility to build pmOS images to meet their use cases, and this makes it easy to add support for new devices and user interfaces in the OS without having to worry about creating conflicts with other devices/UIs.

Device Packages

Device support in postmarketOS is handled through multiple types of packages collectively referred to here as "device packages", that provide an abstraction layer in the OS so that device-specific quirks and configuration can be implemented. These packages are found in pmaports under the devices repo.

There are multiple types of device-related packages:

Device Packages

These packages provide configuration for a single, specific device. They tend to depend on SOC, firmware, and kernel packages in order to provide out-of-the-box support for a device.

Generic Device Packages

These are a special flavor of device packages that provide config for a specific class or family of devices, for example generic-x86_64 for supporting general x86_64 computers that are not specific to any manufacturer. These are ideal device packages since they support a wide range of hardware and allow for greater re-use of config without having to create many individual device packages.

SOC Packages

Some devices, more commonly phones and tablets, have a specific SOC that might be shared among multiple similar devices. In many cases these devices have other quirks that might be incompatible with each other, so it may not be possible to put them into a "generic" device package. SOC packages allow us to re-use SOC-specific configuration in these situations and reducing redundancy. Single device packages will depend on an SOC package if it is relevant for the device.

Firmware Packages

Many consumer electronics contain a multitude of chips in them, and these tend to require loading firmware from userspace to support features and functionality. A very common case is requiring firmware for WiFi and/or Bluetooth functionality. Any firmware required by a device is found in these packages, and these packages have names like firmware-ath6kl and firmware-pine64-ov5640. Device and SOC packages tend to depend on these where appropriate. It's up to device maintainers to determine whether the dependency on specific firmware packages is a hard dependency or a soft one, where a soft dependency is one that allows users to remove the firmware.

Kernel Packages

Device and SOC packages depend on a kernel to add required drivers, and in pmOS many devices do not have mainline kernel support. Kernel packages will provide a specific kernel + patches known to work for a given device. In some cases multiple devices/SOCs can use the same kernel. For devices with good mainline kernel support, they should depend on kernels packaged in Alpine Linux (e.g. linux-lts.) Kernel packages in postmarketOS may include a current mainline kernel, or they may contain an older downstream kernel from some manufacturer either because there is no mainline support or to serve as a reference for mainline work/debug on that device. It's possible for a device package to offer multiple options for kernels to install, e.g. one with a mainline kernel and maybe reduced feature set or an option to install a featureful but outdated downstream kernel.

UI Packages

User interfaces (UI) in postmarketOS are installed and configured by dedicated meta packages, one for each UI. This allows the distro to be somewhat agnostic to UIs in general, allowing users and manufacturers a lot of flexibility to choose the UI they prefer without having to worry about conflicting with other UI configuration. In pmaports, these packages are found in the main repo and have names like postmarketos-ui-gnome and postmarketos-ui-plasma-mobile. Installation of these packages is currently done when the pmOS image is built with pmbootstrap init, and users are not expected to install them directly. There are tentative future plans to make it easier for users to switch/change UIs after installation.

Base Packages

postmarketos-base provides default configuration and dependencies for core pmOS functionality. This package also implements a number of subpackages that are installed conditionally in order to keep the rootfs lightweight. For example, postmarketos-base-mesa will only be installed if Mesa3D is installed on the system, and it pulls in some other packages that are useful for using Mesa on pmOS.

postmarketos-base-ui-* packages exist to provide a shared, re-usable default configuration for families of user interfaces. For example, there is a postmarketos-base-ui-gnome package that Phosh, GNOME Mobile, and GNOME desktop depend on, and this package provides some useful default applications and config for all three UIs without having to duplicate this config across multiple individual UI packages.