Let's mark functions that accept the 'more' flag explicitly for that,
and validate for this explicitly.
This is preparation for
https://github.com/varlink/varlink.github.io/issues/26, if we get that
one day. Let's make sure that from day #1 we have this info available
even if we don't generate this in the IDL for now.
Also enables the two flags for all interfaces we export that use the
logic.
This is the same as json_dispatch_user_group_name() but fills in the
string as "const char*" to the JSON field. Or in other words, it's what
sd_json_dispatch_const_string() is to sd_json_dispatch_string().
Note this drops the SD_JSON_STRICT flags from various dispatch tables
for these fields, and replaces this by SD_JSON_RELAX, i.e. the opposite
behaviour. As #34558 correctly suggests we should validate user names
in lookup functions using the lax rules, rather than the strict ones,
since clients not knowing the rules might ask us for arbitrary
resolution.
(SD_JSON_RELAX internally translates to valid_user_group_name() with the
VALID_USER_RELAX flag).
See: #34558
With many fds the global windows count generally exceeds the
minimum. This results in always reusing the unused entry if
there is one, which becomes a sort of degenerate case where we're
just constantly unmapping->mapping.
Instead let's try always have at least several unused windows on
the unused list before we resort to churning through it.
Fixes#34516
Let's also rename the error slightly, since what happens here is that a
a valid service RR name is CNAME'd onto an invalid one. That's an
inconsistency on the server side, which we really should report as such.
Follow-up for: b48ab08732
Currently, if for example a traffic control object already exist, networkd
will silently do nothing, even if the settings in the network file for the
traffic control object have changed. Let's instead replace the object if it
already exists so that new settings from the network file are applied as
expected.
Fixes#31226
This fixes a bug introduced during review of sysupdated. Originally,
we just returned EALREADY verbatim to signify that the target is
already up-to-date. Then we switched this to a proper error
(org.freedesktop.sysupdate1.NoCandidate) during review. But that now
maps to EIO, not EALREADY. Thus, whenever there's nothing to update,
updatectl would report I/O errors to the user, even though nothing
actually went wrong.
Follow-up for bab889c51e (#33032).
Currently, they unconditionally returns EPOLLIN and USEC_INFINITY, respectively.
Just for consistency with sd-bus, sd-journal, sd-varlink, and so on. All
they have _get_fd(), _get_events(), and _get_timeout().
Closes#34094.
As workarounded by fc0cbed2db, the pair of
subsystem and sysname is not unique. For examples,
- /sys/bus/gpio and /sys/class/gpio, both have gpiochip%N. However, these point to different devpaths.
- /sys/bus/mdio_bus and /sys/class/mdio_bus,
- /sys/bus/mei and /sys/class/mei,
- /sys/bus/typec and /sys/class/typec, and so on.
Let's refuse to provide sd_device object in such cases.
To create the sd_device object of a driver, the function
sd_device_new_from_subsystem_sysname() requires "drivers" for subsystem
and e.g. "pci:iwlwifi" for sysname. Similarly, sd_device_new_from_device_id()
also requires driver subsystem. However, we have never provided a
way to get the driver subsystem ("pci" for the previous example) from
an existing sd_device object.
Let's introduce a way to get driver subsystem.
This partially reverts the commit 730b76bd2c.
Before the commit, the function returned 0 on success, but the commit
made the function always return 1, as if device->devtype is NULL, the
function returns -ENOENT in the above.
Fortunately, udev_device_get_devtype() does not propagate any
non-negative value from sd_device_get_devtype(). Hence, hopefully we can
safely revert the change.
This fixes the following issues:
- We have a journal file, which contains entries of boot A and B. Let T
be the timestamp of the _last_ entry of boot A.
If sd_journal_seek_monotonic_usec() is called for boot A with a timestamp
_after_ T, following sd_journal_next() will provide the _first_ entry of
boot A, rather than the first entry of boot B.
- We have two journal files X and Y. The file X contains entries of boot A.
Let T be the timestamp of the _last_ entry of boot A in file X. The file Y
contains entries of boot A after timestamp T.
If sd_journal_seek_monotonic_usec() is called for boot A with a
timestamp _after_ T, following sd_journal_next() will provide the
_first_ entry of boot A, whose timestamp is of course earlier than T.
Mike Yuan
Lennart Poettering
Vito Caputo
Yu Watanabe
Daan De Meyer
Adrian Vovk