Design: Difference between revisions
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 | 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.