blob: 11f59a437cc52f4b876ca8f5a57f19d2b08fc9db [file] [log] [blame]
mosys - The more open system tool
Introduction
------------
Mosys is designed to aid in obtaining obscure system-specific information
and present it in a uniform, human-friendly manner that is also parseable. It
is intended to complement other systems software and may overlap in some areas.
Examples of information this program is useful for:
- Platform identification
- Snapshot of machine information
- Listing non-enumerable devices
- Retrieving vital product data
Due to the system-specific nature of this program, it is unlikely to work with
most platforms. A generic subset of functionality will be available, though
its usefulness may be extremely limited.
Configuration & Building
------------------------
Dependencies:
libfmap
libuuid
libfdt (typically from the dtc package in your distribution)
Mosys is a two-stage compile: the first stage is for all of the C components and
uses the Meson build system and the second stage is Rust Cargo for all of the
Rust components.
Chrome OS contributors will want to use cros_workon instead. Using the ebuild is
vastly easier than trying to build manually.
See meson.build for valid arch options.
Flags of interest:
-Duse_cros_config=true/false: whether to enable linking to cros_config for
Chrome OS. See Chrome OS example in Mosys ebuild.
Note that you might have better luck compiling Mosys with Clang while -Werror is
enabled. This is because we (Chromium) use Clang as our default compiler. To do
that, add CC=clang before you invoke Meson.
All of this should look something like, for the C components:
CC=clang meson -Darch=amd64 output_dir
ninja -C output_dir
or:
CC=clang meson -Darch=amd64 -Duse_cros_config=true output_dir
ninja -C output_dir
To build with use_cros_config=true, you need one file that is dynamically
provided as inputs to the build process from other ebuilds in the Chrome OS
build system:
lib/cros_config/cros_config_data.c
You can use -Dcros_config_data_src to override the config file that will be used
by the build system.
If you just want to compile something quickly, you can do:
cp lib/cros_config/dummy_cros_config_data.c lib/cros_config/cros_config_data.c
and then run the `meson` command as above.
Then, to build the Rust components, first build the C components using the
instructions above. Then, run:
MESON_BUILD_ROOT=output_dir cargo build
If you are building with use_cros_config, as above, instead you will do:
MESON_BUILD_ROOT=output_dir USE=unibuild cargo build
In the end, this will output a "target/debug/mosys" binary that is dynamically
linked. Use `--release` argument to `cargo` to get a release build.
The `mosys` binary that is output will typically abort on most platforms when
run as a user without root privs. To try to work with this locally without
moving it to a target platform, you can run:
sudo mosys --help
or:
sudo mosys -j -p dummy
to disable the Minijail and force the platform to the "dummy" platform.
To run tests (with cros_config enabled):
CC=clang meson -Darch=amd64 -Duse_cros_config=true -Dtest_cros_config=true out
ninja -C out
USE=unibuild MESON_BUILD_ROOT=out cargo test
Usage
-----
Mosys uses a natural language syntax to navigate thru a command hierarchy for
a given platform. Each supported platform will have a specific set of commands
available.
Typically, top-level commands will reflect classes of hardware components
such as "cpu" or "sensor", available busses such as "pci" or "i2c", or a
type of information such as "smbios" or "vpd".
Mosys returns EXIT_SUCCESS upon successful completion of a command, or
EXIT_FAILURE if a command is not supported on a given platform. These values
are defined in the system's stdlib.h. In case of failure, Mosys will also print
a message to stderr to let the user know.
Use "mosys -t" to display the command tree for the host platform.
Debugging
---------
Mosys uses a minijail to restrict behavior. This can sometimes restrict desired
behavior, especially system calls not whitelisted by the seccom filter.
If a subcommand is returning with an error that should be passing, this might
be why. In order to debug this, run seccomp_debug.sh with the failing command.
This will print out the system calls that caused the run to fail.
Ex. 'mosys platform id' failing on DUT
On the DUT, copy over seccomp_debug.sh and run:
./seccomp_debug.sh mosys platform id