IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
A system that is running on a logical partition (LPAR) provided by
PR/SM has access to physical hardware (except CPU). It is true that
PR/SM abstracts the hardware, but only for sharing purposes.
Details are statet at:
http://publib.boulder.ibm.com/infocenter/eserver/v1r2/topic/eicaz/eicazzlpar.htm
-->--
In other words, PR/SM transforms physical resources into virtual resources so
that many logical partitions can share the same physical resources.
--<--
Still, from the OS point of view, the shared virtual resource is real
hardware. ConditionVirtualization must be set to false if the OS runs
directly on PR/SM (e.g. in an LPAR).
[zj: reorder code so that variables are not allocated when #if-def is
false. Add commit message.]
The sleep(10) in test-journal-send is quite aggressive. We need it only
for the journal to get our cgroup information. But even that information
is not vital to the test, so a sleep(1) should be just fine.
The systemd-subterm example is a stacked terminal that shows how to
use sd-term. Instead of rendering images and displaying it via X11/etc.,
it uses its parent terminal to display the page (terminal-emulator inside
a terminal-emulator) (like GNU-screen and friends do).
This is only for testing and not installed system-wide!
The screen-layer represents the terminal-side (compared to the host-side).
It connects term_parser with term_page and implements all the required
control sequences.
We do not implement all available control sequences. Even though our
parser recognizes them, there is no need to handle them. Most of them are
legacy or unused. We try to be as compatible to xterm, so if we missed
something, we can implement it later. However, all the VT510 / VT440 stuff
can safely be skipped (who needs terminal macros? WTF?).
The keyboard-handling is still missing. It will be added once
systemd-console is available and we pulled in the key-definitions.
The term-parser is used to parse any input from TTY-clients. It reads CSI,
DCS, OSC and ST control sequences and normal escape sequences. It doesn't
do anything with the parsed data besides detecting the sequence and
returning it. The caller has to react to them.
The parser also comes with its own UTF-8 helpers. The reason for that is
that we don't want to assert() or hard-fail on parsing errors. Instead,
we treat any invalid UTF-8 sequences as ISO-8859-1. This allows pasting
invalid data into a terminal (which cannot be controlled through the TTY,
anyway) and we still deal with it in a proper manner.
This is _required_ for 8-bit and 7-bit DEC modes (including the g0-g3
mappings), so it's not just an ugly fallback because we can (it's still
horribly ugly but at least we have an excuse).
The page-layer is a one-dimensional array of lines. Combined with the
one-dimensional lines, you get a two-dimensional page. However, both
implementations, lines and pages only deal with their own dimension. That
means, lines don't know anything about other lines, and pages don't know
anything about cells.
Apart from pages, this also introduces history objects. A history object
is a scroll-back buffer. As some pages like alt-buffers don't have
histories, we keep them separate.
Pages itself forward all cell-related operations to the related line. Only
line-related operations are directly handled by the page. This is mostly
scrolling and history. To support proper resizing, we also keep a
fill-state just like lines do for cells.
There're 3 supported color-modes: term-color-codes, 256-color-code and
rgb-color. We now use the term-color as default so zero(attr) will do what
you'd expect. Furthermore, we split rgb and 256color so users can forward
them properly without requiring an internal RGB converter.
Furthermore, a "hidden" field according to VT510rm manual is added.
Do not expose link_is_loopback, people should just get this from rtnl directly.
Do not expose NTP servers as IP addresses, these must be strings.
Expose ifindex as int, not unsigned. This is what the kernel (mostly) and glibc uses.
Rather than refetching the link information on ever event, we liston to
rtnl to track them. Much code stolen from resolved.
This will allow us to simplify the sd-network api and don't expose
information available over rtnl.
Check for RES_USE_INET6 before we prefer IPv6 over IPv4, for all our NSS
modules. (Not that the DNS resolver that is configured with this matters
to us, but hey, let's try to be compatible).
The conditional for detection xen virtualization contained a little mistake.
It is checking for i to be empty: 'if (!i) {', but it must check for cap instead,
because: 'cap = strsep(&i, ",")' will set cap to the discovered value and i to
the next value after the separator.
Hence, i would be empty, if there is only control_d in domcap, leading to a wrong
domU detection.
https://bugs.freedesktop.org/show_bug.cgi?id=77271
This commit introduces libsystemd-ui, a systemd-internal helper library
that will contain all the UI related functionality. It is going to be used
by systemd-welcomed, systemd-consoled, systemd-greeter and systemd-er.
Further use-cases may follow.
For now, this commit only adds terminal-page handling based on lines only.
Follow-up commits will add more functionality.
This Pty API wraps the ugliness that is POSIX PTY. It takes care of:
- edge-triggered HUP handling (avoid heavy CPU-usage on vhangup)
- HUP vs. input-queue draining (handle HUP _after_ draining the whole
input queue)
- SIGCHLD vs. HUP (HUP is no reliable way to catch PTY deaths, always
use SIGCHLD. Otherwise, vhangup() and friends will break.)
- Output queue buffering (async EPOLLOUT handling)
- synchronous setup (via Barrier API)
At the same time, the PTY API does not execve(). It simply fork()s and
leaves everything else to the caller. Usually, they execve() but we
support other setups, too.
This will be needed by multiple UI binaries (systemd-console, systemd-er,
...) so it's placed in src/shared/. It's not strictly related to
libsystemd-terminal, so it's not included there.
The Barrier-API simplifies cross-fork() synchronization a lot. Replace the
hard-coded eventfd-util implementation and drop it.
Compared to the old API, Barriers also handle exit() of the remote side as
abortion. This way, segfaults will not cause the parent to deadlock.
EINTR handling is currently ignored for any barrier-waits. This can easily
be added, but it isn't needed so far so I dropped it. EINTR handling in
general is ugly, anyway. You need to deal with pselect/ppoll/... variants
and make sure not to unblock signals at the wrong times. So genrally,
there's little use in adding it.
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.
As long as the number of array entries is relatively small it's nicer to
simply return the number of entries directly, instead of using a size_t*
return parameter for it.
Constructors should return the object they created as first parameter,
except when they are generated as a child/member object of some other
object in which case that should be first.
