View system properties in a GUI
- Shell 100%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
|
||
| examples | ||
| lib/system-properties | ||
| scripts | ||
| .gitignore | ||
| README | ||
| system-properties.talc | ||
| VERSION | ||
system-properties: what this system is made of, in tabs -- a window with
the tabs down its left side and the page of the one chosen beside them,
in a repository of its own, written against the libraries beside it
(../canvas, ../look, ../toolkit) the way ../pad is.
lib/system-properties/pci.talc the PCI devices, read from sysfs
lib/system-properties/usb.talc the USB devices, the same
lib/system-properties/cpu.talc the processor, from /proc/cpuinfo and sysfs
lib/system-properties/network.talc the links, asked of ../network's manager
lib/system-properties/services.talc the services, asked of ../services' supervisor
lib/system-properties/ram.talc the memory, from /proc/meminfo and sysfs
lib/system-properties/gpu.talc the graphics adapters, from sysfs
lib/system-properties/groups.talc devices sorted into categories
system-properties.talc the program: the tab strip, the stack of pages,
the table the General page is
scripts/versions.sh writes build/lib/system-properties/versions.talc
from the VERSION file of each component
scripts/build.sh runs that, then builds bin/system-properties
scripts/regress.sh runs it under ../screen with no card and compares
examples/drive.talc what the regress plays at it
examples/*.ppm the pictures expected
Build:
scripts/build.sh
scripts/regress.sh
which need the installed toolchain (compiler on PATH), ../canvas built
(its fonts), ../look, ../toolkit, and for the regress ../screen built.
Start it from the launcher (`system-properties`) or the screen's -run.
GENERAL is the only tab so far: the kernel, and the toolchain, shell,
canvas, screen, toolkit and desktop, each with its version. The kernel's is asked of the running
kernel; the others are what their VERSION files said at build time (the
toolchain's is the installed one's). The regress pictures therefore
show the host's kernel and differ on another one: retake them with
scripts/regress.sh -update.
PCI lists the devices the kernel found, from /sys/bus/pci/devices (so a
machine without sysfs mounted shows the error instead), in categories
as the Device Manager has them -- the base classes: storage, network,
display, bridge ... -- closed to begin with. Return, or a double press,
opens or closes a category (right and left do too); on a device it
opens a window of everything the kernel says about it: class, vendor,
IDs, subsystem, revision, driver, interrupt, power state, link speed
and width, IOMMU group. Escape or the close button ends that window;
in the main one it ends the program. There is no database of names
here, so the classes and vendors named are the short tables in
lib/system-properties/pci.talc and the rest show as numbers. The
regress pictures are of the machine they were taken on.
USB lists the USB devices -- hubs, the host controllers' root hubs and
what is plugged in -- from /sys/bus/usb/devices, in categories by class
(a device that leaves its class to its interfaces, as a mouse does, is
filed by its first interface's), and opens the same way: a window of
product, manufacturer, serial number, IDs, USB version, speed, power,
bus and driver. Devices are named by what they say of themselves, so
only the classes have a table (lib/system-properties/usb.talc). PCI and
USB share the grouping (lib/system-properties/groups.talc) and the
tree in system-properties.talc.
CPU is the processor as /proc/cpuinfo and the cpu directory of sysfs say:
model, vendor, family/model/stepping, microcode, sockets, cores, logical
processors, highest speed, caches, address sizes, virtualization (VT-x
or AMD-V) and the features a person asks about (SSE4.2, AVX, AES ...).
A line the kernel does not give is left out. The speed it runs at now is
not shown: it would change the regress picture on every run. It is the
x86 reading; another family's cpuinfo has other names.
Its caches and top speed come from sysfs, which the machine's kernel may
not have (no cpufreq in the tinyconfig one), and then are left out.
RAM is the memory as the firmware describes it: the SMBIOS tables
(/sys/firmware/dmi/tables/DMI) list the memory array -- slots in use,
the most it can hold, error correction -- and each slot: the size,
type (DDR5, LPDDR5 ...), form factor, rated speed, the speed it runs at
when that differs, the maker and the part number. Beside them the total
the kernel counts, which is less than what is installed. Nothing here
changes while it is looked at. The file is the superuser's: unreadable,
the slot lines give way to a note. Which also needs a kernel with
CONFIG_DMI and CONFIG_DMI_SYSFS (../vm's has them since the RAM tab).
The parser was tried on tables built to the specification (a DDR5
SODIMM with a configured speed, an empty slot) and on qemu's own in the
vm; the regress picture is of the host, where the tables are not
readable to a person, and shows the note.
GPU lists the graphics adapters: every PCI device of the display class,
driver or not, from /sys/bus/pci/devices, with a blank line between
adapters -- the vendor and numbers, address, the kernel driver bound
to it, video memory and shared memory where the driver says (amdgpu
does), the PCIe link, whether it is the primary one, its /dev/dri node,
and each connected display with the mode it prefers. The driver is the
bus driver sysfs gives (virtio-pci for a virtio card); the graphics
driver's own name takes an ioctl, which is not here. Names are not
looked up (see PCI): an adapter is its vendor and its numbers.
NETWORK is what the network manager (../network) says over its socket --
NETWORK in the environment, which the screen's programs inherit from
the shell that started the screen: one line per link with its kind, its
state (unmanaged, down, up, carrier, addressing, connected, held), its
addresses, the default route it gives and the profile applied, then the
name servers. With no manager to ask, the one line says so. The regress
picture is taken with none.
ANOTHER TAB is one line in `tabs`: a name and a function that makes its
page, a part. Nothing is drawn but through the theme, so every look
styles it (the table asks for a `table` style, the lists' by default).
There are no graphics yet, only names and numbers.
SERVICES lists the services as the supervisor (../services) runs them,
asked over its socket (SERVICES in the environment): each with its state,
how long it has been so, its process, its restarts and how it last
ended; with no supervisor to ask, the line that says so. The regress
picture is that line.