| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
Multiple executables do not need libsystemd-core
|
|
TEST_DIR is already defined in AM_CFLAGS
|
|
It tests all available directives of Path units:
- PathChanged
- PathModified
- PathExists
- PathExisysGlob
- DirectoryNotEmpty
- MakeDirectory
- DirectoryMode
- Unit
|
|
Now that we only have one file with condition implementations around, we
can drop the -util suffix and simplify things a bit.
|
|
That way only one file with condition code remaining, in src/shared/,
rather than src/core/.
Next step: dropping the "-util" suffix from condition-util.[ch].
|
|
Also, implement the negation check inside of condition_test() instead of
individually in each test function.
|
|
|
|
The initialization performed by systemd-vconsole-setup is reset
when changing console drivers (say from vgacon to fbcon), so we
need to run it in that case.
See
http://lists.freedesktop.org/archives/systemd-devel/2014-October/023919.html
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024423.html
http://lists.freedesktop.org/archives/systemd-devel/2014-November/024881.html
This commit adds a udev rule to make systemd-vconsole-setup get run when
the fbcon device becomes available.
(david: moved into new file 90-vconsole.rules instead of 71-seats.rules;
build-failures are on me, not on Ray)
|
|
|
|
|
|
This library negotiates a PPPoE channel. It handles the discovery stage and
leaves the session stage to the kernel. A further PPP library is needed to
actually set up a PPP unit (negotatie LCP, IPCP and do authentication), so in
isolation this is not yet very useful.
The test program has two modes:
# ./test-pppoe
will create a veth tunnel in a new network namespace, start pppoe-server on one
end and this client library on the other. The pppd server will time out as no
LCP is performed, and the client will then shut down gracefully.
# ./test-pppoe eth0
will run the client on eth0 (or any other netdev), and requires a PPPoE server
to be reachable on the local link.
|
|
|
|
|
|
|
|
I tried to preserve most errno values, but in some cases they were
inconsistent (different errno values for the same error name) or just
mismatched.
|
|
This allows custom "name" ↔ errno mappings to be registered.
Tables from all compilation units are concatenated.
|
|
$ sudo gdb -p 1
...
(gdb) source gdb-sd_dump_hashmaps.py
(gdb) sd_dump_hashmaps
... lists allocated hashmaps ...
(gdb) sd_dump_hashmaps 1
... lists allocated hashmaps, their DIB histograms and contiguous
blocks statistics ...
|
|
This is a rewrite of the hashmap implementation. Its advantage is lower
memory usage.
It uses open addressing (entries are stored in an array, as opposed to
linked lists). Hash collisions are resolved with linear probing and
Robin Hood displacement policy. See the references in hashmap.c.
Some fun empirical findings about hashmap usage in systemd on my laptop:
- 98 % of allocated hashmaps are Sets.
- Sets contain 78 % of all entries, plain Hashmaps 17 %, and
OrderedHashmaps 5 %.
- 60 % of allocated hashmaps contain only 1 entry.
- 90 % of allocated hashmaps contain 5 or fewer entries.
- 75 % of all entries are in hashmaps that use trivial_hash_ops.
Clearly it makes sense to:
- store entries in distinct entry types. Especially for Sets - their
entries are the most numerous and they require the least information
to store an entry.
- have a way to store small numbers of entries directly in the hashmap
structs, and only allocate the usual entry arrays when the direct
storage is full.
The implementation has an optional debugging feature (enabled by
defining the ENABLE_HASHMAP_DEBUG macro), where it:
- tracks all allocated hashmaps in a linked list so that one can
easily find them in gdb,
- tracks which function/line allocated a given hashmap, and
- checks for invalid mixing of hashmap iteration and modification.
Since entries are not allocated one-by-one anymore, mempools are not
used for entries. Originally I meant to drop mempools entirely, but it's
still worth it to use them for the hashmap structs. My testing indicates
that it makes loading of units about 5 % faster (a test with 10000 units
where more than 200000 hashmaps are allocated - pure malloc: 449±4 ms,
mempools: 427±7 ms).
Here are some memory usage numbers, taken on my laptop with a more or
less normal Fedora setup after booting with SELinux disabled (SELinux
increases systemd's memory usage significantly):
systemd (PID 1) Original New Change
dirty memory (from pmap -x 1) [KiB] 2152 1264 -41 %
total heap allocations (from gdb-heap) [KiB] 1623 756 -53 %
|
|
provided headers
|
|
|
|
|
|
|
|
|
|
test-hashmap-ordered.c is generated from test-hashmap-plain.c simply by
substituting "ordered_hashmap" for "hashmap" etc.
In the cases where tests rely on the order of entries, a distinction
between plain and ordered hashmaps is made using the ORDERED macro,
which is defined only for test-hashmap-ordered.c.
|
|
It was only used in readahead.
|
|
The unit file is statically enabled, but still requires --enable-terminal
to actually get installed.
|
|
This should not normally be run manually, but rather through systemd.
|
|
|
|
|
|
This adds a first draft of systemd-consoled. This is still missing a lot
of features and does some rather primitive rendering. However, it shows
the direction this code is going and serves as basis for further testing.
The systemd-consoled binary should be run as `systemd --user' unit. It
automatically picks up any session marked as Desktop=SYSTEMD-CONSOLE.
Therefore, you can use any login-manager you want (ranging from /bin/login
to gdm) to create sessions for systemd-consoled. However, the sessions
managers must be prepared to set the Desktop= variable properly.
The user-session is called `systemd-console', only the daemon providing
the terminal environment is called `systemd-consoled' (mind the 'd').
So far, only a single terminal session is provided on each opened
user-session. However, we support multiple user-sessions (even across
multiple seats) just fine. In the future, the workspace logic will get
extended so you can have multiple terminal sessions in a single
user-session for easier access.
Note that this is still experimental! Instructions on how to run it will
follow shortly.
|
|
Like all the other parts of libsystemd-terminal, split API of
term-internal.h into term.h so we can use it from systemd-consoled.
|
|
Lets avoid putting stuff into /usr/shared/unifont/, but keep it in
/usr/share/systemd/. Upstream lacks interest in this, so don't bother for
now.
|
|
All the definitions are for outside users, so drop the -internal suffix.
Internal definitions are in unifont-def.h and unifont.c, no need to share
those.
|
|
Just to make sure that coverity is wrong.
|
|
|
|
This adds --disable-utmp option to configure. If it is used, all
utmp-related functionality, including querying runlevel support,
is removed.
|
|
This reverts commit ef99aec4d25087dec995b3f00b6957dcee6b13e9.
systemd-stdio-bridge is used on non-kdbus systems.
|
|
|
|
It was added to EXTRA_DIST in 3c3e5f4276a893791110b03984735654372aa33a,
but this script only makes sense for developers.
|
|
|
|
|
|
Add some test files and routines for dbus policy checking.
|
|
The systemd-modeset tool is meant to debug grdev issues. It simply
displays morphing colors on any found display. This is pretty handy to
look for tearing in the backends and debug hotplug issues.
Note that this tool requires systemd-logind to be compiled from git
(there're important fixes that haven't been released, yet).
|
|
The grdev-drm backend manages DRM cards for grdev. Any DRM card with
DUMB_BUFFER support can be used. So far, our policy is to configure all
available connectors, but keep pipes inactive as long as users don't
enable the displays on top.
We hard-code double-buffering so far, but can easily support
single-buffering or n-buffering. We also require XRGB8888 as format as
this is required to be supported by all DRM drivers and it is what VTs
use. This allows us to switch from VTs to grdev via page-flips instead of
deep modesets.
There is still a lot room for improvements in this backend, but it works
smoothly so far so more enhanced features can be added later.
|
|
The grdev layer provides graphics-device access via the
libsystemd-terminal library. It will be used by all terminal helpers to
actually access display hardware.
Like idev, the grdev layer is built around session objects. On each
session object you add/remove graphics devices as they appear and vanish.
Any device type can be supported via specific card-backends. The exported
grdev API hides any device details.
Graphics devices are represented by "cards". Those are hidden in the
session and any pipe-configuration is automatically applied. Out of those,
we configure displays which are then exported to the API user. Displays
are meant as lowest hardware entity available outside of grdev. The
underlying pipe configuration is fully hidden and not accessible from the
outside. The grdev tiling layer allows almost arbitrary setups out of
multiple pipes, but so far we only use a small subset of this. More will
follow.
A grdev-display is meant to represent real connected displays/monitors.
The upper level screen arrangements are user policy and not controlled by
grdev. Applications are free to apply any policy they want.
Real card-backends will follow in later patches.
|
