David Herrmann [Thu, 12 Jun 2014 15:51:14 +0000 (17:51 +0200)]
ui/term: add line/cell/char handling for terminal pages
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.
David Herrmann [Fri, 11 Jul 2014 14:29:56 +0000 (16:29 +0200)]
shared: add PTY helper
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.
David Herrmann [Sun, 13 Jul 2014 10:14:45 +0000 (12:14 +0200)]
nspawn: use Barrier API instead of eventfd-util
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.
David Herrmann [Thu, 10 Jul 2014 13:25:47 +0000 (15:25 +0200)]
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):
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.
sd-network: remove redundant array size parameter from functions that return arrays
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.
sd-network: fix parameter order for sd_network_monitor_new()
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.
Special care is needed so that we get an error message if the
file failed to parse, but not when it is missing. To avoid duplicating
the same error check in every caller, add an additional 'warn' boolean
to tell config_parse whether a message should be issued.
This makes things both shorter and more robust wrt. to error reporting.
Michael Olbrich [Tue, 15 Jul 2014 16:28:10 +0000 (18:28 +0200)]
units/serial-getty@.service: use the default RestartSec
For pluggable ttys such as USB serial devices, the getty is restarted
and exits in a loop until the remove event reaches systemd. Under
certain circumstances the restart loop can overload the system in a
way that prevents the remove event from reaching systemd for a long
time (e.g. at least several minutes on a small embedded system).
Use the default RestartSec to prevent the restart loop from
overloading the system. Serial gettys are interactive units, so
waiting an extra 100ms really doesn't make a difference anyways
compared to the time it takes the user to log in.
Instead of copying fields into new memory allocations, simply keep pointers
into the receive buffer. Data in this buffer is only copied when there is not
enough space for new data and a large chunk of the buffer contains old data.
Clear up confusion wrt. ENTRY_SIZE_MAX and DATA_SIZE_MAX
Define DATA_SIZE_MAX to mean the maximum size of a single
field, and ENTRY_SIZE_MAX to mean the size of the whole
entry, with some rough calculation of overhead over the payload.
Check if entries are not too big when processing native journal
messages.
journal-remote: allow splitting incoming logs by source host
Previously existing scheme where the file name would be based on
the source was just too ugly and unpredicatable. Now there are
only two options:
1. just one file (until rotation),
2. one file per source host, using the hostname as filename part.
For the cases where the source is specified by the user, only
option one is allowed, and the full of the file must be specified.
Move network-related journal programs to src/journal-remote/
Directory src/journal has become one of the largest directories,
and since systemd-journal-gatewayd, systemd-journal-remote, and
forthcoming systemd-journal-upload are all closely related, create
a separate directory for them.
If a file was opened for writing, and then closed immediately without
actually writing any entries, on subsequent opening, it would be
considered "corrupted". This should be totally fine, and even in
read mode, an empty file can become non-empty later on.
Tom Gundersen [Tue, 15 Jul 2014 16:55:31 +0000 (18:55 +0200)]
sd-dhcp-client: make request broadcasts opt-in
It appears there is no good way to decide whether or not broadcasts should be enabled,
there is hardware that must have broadcast, and there are networks that only allow
unicast. So we give up and make this configurable.
By default, unicast is used, but if the kernel were to inform us abotu certain
interfaces requiring broadcast, we could change this to opt-in by default in
those cases.
Kay Sievers [Tue, 15 Jul 2014 15:35:53 +0000 (17:35 +0200)]
rules: uaccess - add ID_SOFTWARE_RADIO
On Tue, Jul 15, 2014 at 1:52 PM, Alick Zhao <alick9188@gmail.com> wrote:
>>>
>>> So maybe ID_SOFTWARE_RADIO ?
>>
>> Hmm, SDR is more a term for a generic technology than for a device
>> class. To me it does not really sound like an administrator would know
>> what this is.
>>
>> What exactly is the device or subsystem you want to make accessible to
>> locally logged-in users only?
>
> Initially it is bladeRF, but many more are of interest: USRP, rtl-sdr,
> HackRF, ... [1]
>
> I agree an administrator might not know what SDR is, since it is
> currently still not widely known, and makes sense only for amateurs
> and researchers. But as a SDR fan, I see many new SDR peripherals
> are created recently, and expect to see more. So a generic ID seems
> reasonable to me.
>
> [1] http://en.wikipedia.org/wiki/List_of_software-defined_radios
timesyncd: only listen to clock changes when connected
This reverts previous commit and applies a different fix.
manager_clock_watch() callback calls manager_send_request() to kick
off a resync. We can only do that when we're actually connected to
something. It is not useful to setup the callback from manager_new().
Now the callback will be dropped in manager_connect() and requested
in manager_begin().