Commit graph

9 commits

Author SHA1 Message Date
Yu Watanabe db9ecf0501 license: LGPL-2.1+ -> LGPL-2.1-or-later 2020-11-09 13:23:58 +09:00
Zbigniew Jędrzejewski-Szmek d284b82b3e Move various files that don't need to be in basic/ to shared/
This doesn't have much effect on the final build, because we link libbasic.a
into libsystemd-shared.so, so in the end, all the object built from basic/
end up in libsystemd-shared. And when the static library is linked into binaries,
any objects that are included in it but are not used are trimmed. Hence, the
size of output artifacts doesn't change:

$ du -sb /var/tmp/inst*
54181861	/var/tmp/inst1    (old)
54207441	/var/tmp/inst1s   (old split-usr)
54182477	/var/tmp/inst2    (new)
54208041	/var/tmp/inst2s   (new split-usr)

(The negligible change in size is because libsystemd-shared.so is bigger
by a few hundred bytes. I guess it's because symbols are named differently
or something like that.)

The effect is on the build process, in particular partial builds. This change
effectively moves the requirements on some build steps toward the leaves of the
dependency tree. Two effects:
- when building items that do not depend on libsystemd-shared, we
  build less stuff for libbasic.a (which wouldn't be used anyway,
  so it's a net win).
- when building items that do depend on libshared, we reduce libbasic.a as a
  synchronization point, possibly allowing better parallelism.

Method:
1. copy list of .h files from src/basic/meson.build to /tmp/basic
2. $ for i in $(grep '.h$' /tmp/basic); do echo $i; git --no-pager grep "include \"$i\"" src/basic/ 'src/lib*' 'src/nss-*' 'src/journal/sd-journal.c' |grep -v "${i%.h}.c";echo ;done | less
2018-11-20 07:27:37 +01:00
Kay Sievers a095315b3c build-sys: split internal basic/ library from shared/
basic/      can be used by everything
            cannot use anything outside of basic/

libsystemd/ can use basic/
            cannot use shared/

shared/     can use libsystemd/
2015-06-11 10:52:46 +02:00
Zbigniew Jędrzejewski-Szmek dc75168823 Use space after a silencing (void)
We were using a space more often than not, and this way is
codified in CODING_STYLE.
2015-03-13 23:42:17 -04:00
Thomas Hindoe Paaboel Andersen 2eec67acbb remove unused includes
This patch removes includes that are not used. The removals were found with
include-what-you-use which checks if any of the symbols from a header is
in use.
2015-02-23 23:53:42 +01:00
David Herrmann dfb05a1cf5 barrier: explicitly ignore return values of barrier_place()
The barrier implementation tracks remote states internally. There is no
need to check the return value of any barrier_*() function if the caller
is not interested in the result. The barrier helpers only return the state
of the remote side, which is usually not interesting as later calls to
barrier_sync() will catch this, anyway.

Shut up coverity by explicitly ignoring return values of barrier_place()
if we're not interested in it.
2014-11-04 09:49:43 +01:00
David Herrmann fc80861622 barrier: fix up constructor error handling
We cannot rely on "errno" to be non-zero on failure, if we perform
multiple glibc calls. That is, if the first eventfd() call fails, but the
second succeeds, we cleanup the barrier but return 0.

Fix this by always testing the return value immediately. This should also
fix all the coverity warnings.
2014-10-02 08:40:43 +02:00
Zbigniew Jędrzejewski-Szmek 7566e26721 barrier: initalize file descriptors with -1
Explicitly initalize descriptors using explicit assignment like
bus_error. This makes barriers follow the same conventions as
everything else and makes things a bit simpler too.

Rename barier_init to barier_create so it is obvious that it is
not about initialization.

Remove some parens, etc.
2014-07-18 20:12:44 -04:00
David Herrmann 279da1e3f9 shared: add generic IPC barrier
The "Barrier" object is a simple inter-process barrier implementation. It
allows placing synchronization points and waiting for the other side to
reach it. Additionally, it has an abortion-mechanism as second-layer
synchronization to send abortion-events asynchronously to the other side.

The API is usually used to synchronize processes during fork(). However,
it can be extended to pass state through execve() so you could synchronize
beyond execve().

Usually, it's used like this (error-handling replaced by assert() for
simplicity):

    Barrier b;

    r = barrier_init(&b);
    assert_se(r >= 0);

    pid = fork();
    assert_se(pid >= 0);
    if (pid == 0) {
            barrier_set_role(&b, BARRIER_CHILD);

            ...do child post-setup...
            if (CHILD_SETUP_FAILED)
                       exit(1);
            ...child setup done...

            barrier_place(&b);
            if (!barrier_sync(&b)) {
                    /* parent setup failed */
                    exit(1);
            }

            barrier_destroy(&b); /* redundant as execve() and exit() imply this */

            /* parent & child setup successful */
            execve(...);
    }

    barrier_set_role(&b, BARRIER_PARENT);

    ...do parent post-setup...
    if (PARENT_SETUP_FAILED) {
            barrier_abort(&b);          /* send abortion event */
            barrier_wait_abortion(&b);  /* wait for child to abort (exit() implies abortion) */
            barrier_destroy(&b);
           ...bail out...
    }
    ...parent setup done...

    barrier_place(&b);
    if (!barrier_sync(&b)) {
            ...child setup failed... ;
            barrier_destroy(&b);
            ...bail out...
    }

    barrier_destroy(&b);

    ...child setup successfull...

This is the most basic API. Using barrier_place() to place barriers and
barrier_sync() to perform a full synchronization between both processes.
barrier_abort() places an abortion barrier which superceeds any other
barriers, exit() (or barrier_destroy()) places an abortion-barrier that
queues behind existing barriers (thus *not* replacing existing barriers
unlike barrier_abort()).

This example uses hard-synchronization with wait_abortion(), sync() and
friends. These are all optional. Barriers are highly dynamic and can be
used for one-way synchronization or even no synchronization at all
(postponing it for later). The sync() call performs a full two-way
synchronization.

The API is documented and should be fairly self-explanatory. A test-suite
shows some special semantics regarding abortion, wait_next() and exit().

Internally, barriers use two eventfds and a pipe. The pipe is used to
detect exit()s of the remote side as eventfds do not allow that. The
eventfds are used to place barriers, one for each side. Barriers itself
are numbered, but the numbers are reused once both sides reached the same
barrier, thus you cannot address barriers by the index. Moreover, the
numbering is implicit and we only store a counter. This makes the
implementation itself very lightweight, which is probably negligible
considering that we need 3 FDs for a barrier..

Last but not least: This barrier implementation is quite heavy. It's
definitely not meant for fast IPC synchronization. However, it's very easy
to use. And given the *HUGE* overhead of fork(), the barrier-overhead
should be negligible.
2014-07-17 11:34:00 +02:00