David Herrmann
e202fa31fb
The idev-interface provides input drivers for all libsystemd-terminal
based applications. It is split into 4 main objects:
idev_context: The context object tracks global state of the input
interface. This will include data like system-keymaps,
xkb contexts and more.
idev_session: A session serves as controller for a set of devices.
Each session on an idev-context is independent of each
other. The session is also the main notification object.
All events raised via idev are reported through the
session interface. Apart of that, the session is a
pretty dumb object that just contains devices.
idev_element: Elements provide real hardware in the idev stack. For
each hardware device, one element is added. Elements
have no knowledge of higher-level device types, they
only provide raw input data to the upper levels. For
example, each evdev device is represented by a different
element in an idev session.
idev_device: Devices are objects that the application deals with. An
application is usually not interested in elements (and
those are hidden to applications), instead, they want
high-level input devices like keyboard, touchpads, mice
and more. Device are the high-level interface provided
by idev. Each device might be fed by a set of elements.
Elements drive the device. If elements are removed,
devices are destroyed. If elements are added, suitable
devices are created.
Applications should monitor the system for sessions and hardware devices.
For each session they want to operate on, they create an idev_session
object and add hardware to that object. The idev interface requires the
application to monitor the system (preferably via sysview_*, but not
required) for hardware devices. Whenever hardware is added to the idev
session, new devices *might* be created. The relationship between hardware
and high-level idev-devices is hidden in the idev-session and not exposed.
Internally, the idev elements and devices are virtual objects. Each real
hardware and device type inherits those virtual objects and provides real
elements and devices. Those types will be added in follow-up commits.
Data flow from hardware to the application is done via idev_*_feed()
functions. Data flow from applications to hardware is done via
idev_*_feedback() functions. Feedback is usually used for LEDs, FF and
similar operations.
systemd System and Service Manager
DETAILS:
http://0pointer.de/blog/projects/systemd.html
WEB SITE:
http://www.freedesktop.org/wiki/Software/systemd
GIT:
git://anongit.freedesktop.org/systemd/systemd
ssh://git.freedesktop.org/git/systemd/systemd
GITWEB:
http://cgit.freedesktop.org/systemd/systemd
MAILING LIST:
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
http://lists.freedesktop.org/mailman/listinfo/systemd-commits
IRC:
#systemd on irc.freenode.org
BUG REPORTS:
https://bugs.freedesktop.org/enter_bug.cgi?product=systemd
AUTHOR:
Lennart Poettering
Kay Sievers
...and many others
LICENSE:
LGPLv2.1+ for all code
- except sd-readahead.[ch] which is MIT
- except src/shared/MurmurHash2.c which is Public Domain
- except src/shared/siphash24.c which is CC0 Public Domain
- except src/journal/lookup3.c which is Public Domain
- except src/udev/* which is (currently still) GPLv2, GPLv2+
REQUIREMENTS:
Linux kernel >= 3.0
Linux kernel >= 3.3 for loop device partition support features with nspawn
Linux kernel >= 3.8 for Smack support
Kernel Config Options:
CONFIG_DEVTMPFS
CONFIG_CGROUPS (it is OK to disable all controllers)
CONFIG_INOTIFY_USER
CONFIG_SIGNALFD
CONFIG_TIMERFD
CONFIG_EPOLL
CONFIG_NET
CONFIG_SYSFS
CONFIG_PROC_FS
CONFIG_FHANDLE (libudev, mount and bind mount handling)
Udev will fail to work with the legacy layout:
CONFIG_SYSFS_DEPRECATED=n
Legacy hotplug slows down the system and confuses udev:
CONFIG_UEVENT_HELPER_PATH=""
Userspace firmware loading is deprecated, will go away, and
sometimes causes problems:
CONFIG_FW_LOADER_USER_HELPER=n
Some udev rules and virtualization detection relies on it:
CONFIG_DMIID
Support for some SCSI devices serial number retrieval, to
create additional symlinks in /dev/disk/ and /dev/tape:
CONFIG_BLK_DEV_BSG
Required for PrivateNetwork in service units:
CONFIG_NET_NS
Optional but strongly recommended:
CONFIG_IPV6
CONFIG_AUTOFS4_FS
CONFIG_TMPFS_POSIX_ACL
CONFIG_TMPFS_XATTR
CONFIG_SECCOMP
Required for CPUShares in resource control unit settings
CONFIG_CGROUP_SCHED
CONFIG_FAIR_GROUP_SCHED
For systemd-bootchart, several proc debug interfaces are required:
CONFIG_SCHEDSTATS
CONFIG_SCHED_DEBUG
For UEFI systems:
CONFIG_EFIVAR_FS
CONFIG_EFI_PARTITION
Note that kernel auditing is broken when used with systemd's
container code. When using systemd in conjunction with
containers, please make sure to either turn off auditing at
runtime using the kernel command line option "audit=0", or
turn it off at kernel compile time using:
CONFIG_AUDIT=n
If systemd is compiled with libseccomp support on
architectures which do not use socketcall() and where seccomp
is supported (this effectively means x86-64 and ARM, but
excludes 32-bit x86!), then nspawn will now install a
work-around seccomp filter that makes containers boot even
with audit being enabled. This works correctly only on kernels
3.14 and newer though. TL;DR: turn audit off, still.
glibc >= 2.14
libcap
libseccomp >= 1.0.0 (optional)
libblkid >= 2.20 (from util-linux) (optional)
libkmod >= 15 (optional)
PAM >= 1.1.2 (optional)
libcryptsetup (optional)
libaudit (optional)
libacl (optional)
libselinux (optional)
liblzma (optional)
liblz4 >= 119 (optional)
libgcrypt (optional)
libqrencode (optional)
libmicrohttpd (optional)
libpython (optional)
libidn (optional)
gobject-introspection > 1.40.0 (optional)
elfutils >= 158 (optional)
make, gcc, and similar tools
During runtime, you need the following additional
dependencies:
util-linux >= v2.19 (requires fsck -l, agetty -s),
v2.21 required for tests in test/
dbus >= 1.4.0 (strictly speaking optional, but recommended)
sulogin (from util-linux >= 2.22 or sysvinit-tools, optional but recommended,
required for tests in test/)
dracut (optional)
PolicyKit (optional)
When building from git, you need the following additional
dependencies:
docbook-xsl
xsltproc
automake
autoconf
libtool
intltool
gperf
gtkdocize (optional)
python (optional)
python-lxml (optional, but required to build the indices)
sphinx (optional)
When systemd-hostnamed is used, it is strongly recommended to
install nss-myhostname to ensure that, in a world of
dynamically changing hostnames, the hostname stays resolvable
under all circumstances. In fact, systemd-hostnamed will warn
if nss-myhostname is not installed.
To build HTML documentation for python-systemd using sphinx,
please first install systemd (using 'make install'), and then
invoke sphinx-build with 'make sphinx-<target>', with <target>
being 'html' or 'latexpdf'. If using DESTDIR for installation,
pass the same DESTDIR to 'make sphinx-html' invocation.
USERS AND GROUPS:
Default udev rules use the following standard system group
names, which need to be resolvable by getgrnam() at any time,
even in the very early boot stages, where no other databases
and network are available:
audio, cdrom, dialout, disk, input, kmem, lp, tape, tty, video
During runtime, the journal daemon requires the
"systemd-journal" system group to exist. New journal files will
be readable by this group (but not writable), which may be used
to grant specific users read access.
It is also recommended to grant read access to all journal
files to the system groups "wheel" and "adm" with a command
like the following in the post installation script of the
package:
# setfacl -nm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/
The journal gateway daemon requires the
"systemd-journal-gateway" system user and group to
exist. During execution this network facing service will drop
privileges and assume this uid/gid for security reasons.
Similarly, the NTP daemon requires the "systemd-timesync" system
user and group to exist.
Similarly, the network management daemon requires the
"systemd-network" system user and group to exist.
Similarly, the name resolution daemon requires the
"systemd-resolve" system user and group to exist.
Similarly, the kdbus dbus1 proxy daemon requires the
"systemd-bus-proxy" system user and group to exist.
NSS:
systemd ships with three NSS modules:
nss-myhostname resolves the local hostname to locally
configured IP addresses, as well as "localhost" to
127.0.0.1/::1.
nss-resolve enables DNS resolution via the systemd-resolved
DNS/LLMNR caching stub resolver "systemd-resolved".
nss-mymachines enables resolution of all local containers
registered with machined to their respective IP addresses.
To make use of these NSS modules, please add them to the
"hosts: " line in /etc/nsswitch.conf. The "resolve" module
should replace the glibc "dns" module in this file.
The three modules should be used in the following order:
hosts: files mymachines resolve myhostname
WARNINGS:
systemd will warn you during boot if /etc/mtab is not a
symlink to /proc/mounts. Please ensure that /etc/mtab is a
proper symlink.
systemd will warn you during boot if /usr is on a different
file system than /. While in systemd itself very little will
break if /usr is on a separate partition, many of its
dependencies very likely will break sooner or later in one
form or another. For example, udev rules tend to refer to
binaries in /usr, binaries that link to libraries in /usr or
binaries that refer to data files in /usr. Since these
breakages are not always directly visible, systemd will warn
about this, since this kind of file system setup is not really
supported anymore by the basic set of Linux OS components.
systemd requires that the /run mount point exists. systemd also
requires that /var/run is a a symlink to /run.
For more information on this issue consult
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
To run systemd under valgrind, compile with VALGRIND defined
(e.g. ./configure CPPFLAGS='... -DVALGRIND=1'). Otherwise,
false positives will be triggered by code which violates
some rules but is actually safe.