hwdb: add database entries for node with multiple units

In IEEE 1394 bus, one node can include multiple units, which represent
certain functions such as video and audio. Although it's possible to
distinguish each unit, Linux FireWire character device corresponding to
the node can not have multiple group owners, therefore it's forced to
select one of the units as representative for function.

This commit adds database entries for units belongs to the same node.
The entries are aligned to inverse order of corresponding unit order
in configuration ROM to select the first unit as the representative.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entry for node with single unit with video function

Cool Stream shipped iSweet. This model has single unit for video function.

This commit adds database entry for it as sample of node with single unit
for video.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for TC Electronic PowerCore FireWire series

TC Electronic had PowerCore platform for products of digital audio signal
processing. This platform consists of NXP PowerQUICC II Processor with PCI
interface (XPC8245, MPC8245), Xilinx Spartan-II FPGA (XC2S50), and some
NXP 24-Bit Audio Digital Signal Processor (DSP56367). The products for
IEEE 1394 bus has additional TI OHCI 1.1, 1394a link layer controller
(TSB43AB23).

The content of configuration ROM has layout of standard of 1394 Trading
Association.

This commit adds database entries for the models. At present, no driver is
developed, thus this is just for convenience to developers.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for Focusrite Liquid Mix series

Sintefex Audio Lda. designed Liquid Mix as OEM of Focusrite Audio
Engineering, Ltd. The models serve digital signal processing service via
asynchronous transaction in IEEE 1394 bus.

The content of configuration ROM is not standard of 1394 Trading
Association.

This commit adds an rule entry for the models. At present, no driver is
developed, thus this is just for convenience to developers.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for Yamaha mLAN 3rd generation

TC Applied Technologies designed DiceII ASIC to adapt to two protocols.
One of the protocol is mLAN defined by Yamaha Corporation, and another
is own protocol. The DiceII ASIC adapted to mLAN protocol was used some
products by Yamaha and its child company, Steinberg.

The content of configuration ROM for the models has completely different
layout from the one defined by 1394 Trading Association.

This commit adds an udev rule for the models. At present, no driver is
developed, thus this is just for convenience to developers.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for Yamaha mLAN 2nd generation

Yamaha Corporation designed mLAN protocol based on IEEE 1394
specification. Yamaha developed specific ICs for the purpose (mLAN-NC1
and mLAN-PH2), and shipped some products with them, as well as OEM.

The content of configuration ROM is completely different from standard
layout defined by 1394 Trading Association.

This commit adds database entries for the models. At present, two vendors
are known for models with mLAN IC. At present, no driver is developed
for the models, thus this is just for convenience to developers.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for RME Fireface series

RME GmbH shipped Fireface series. The configuration ROM in the models of
series has some quirks and against standard of 1394 Trading Association.

This commit adds database entries for the models. ALSA fireface driver
supports them, but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for MOTU FireWire series

Mark of the unicorn (MOTU) shipped FireWire series. The configuration ROM
in the models of series has some quirks and against standard of 1394
Trading Association.

This commit adds database entries for the models. ALSA firewire-motu driver
supports them, but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for Tascam FireWire series

TEAC Corporation shipped FireWire series in its TASCAM brand. The
configuration ROM in the models of series has some quirks and against
standard of 1394 Trading Association.

This commit adds database entries for the models. ALSA firewire-tascam
driver supports them, but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for models of Digidesign Digi 00x family

Avid Audio shipped Digi 00x family in its Digidesign brand. The
configuration ROM in the models of family has some quirks and against
standard of 1394 Trading Association.

This commit adds database entries for the model. ALSA firewire-digi00x
driver supports them, but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for models based on DICE ASICs specialized by Solid State Logic

Solid State Logic, Ltd. shipped some models based on DICE ASICs. The
content of configuration ROM has a quirk that the value of category
field is unique (0x51 or 0x52).

This commit adds database entries for the models. ALSA dice driver supports
them, but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for models based on DICE ASICs specialized by Harman Music Group

Harman International Industries, Inc. shipped some models based on DICE
ASICs in its Lexicon brand. The content of configuration ROM has a quirk
that the value of category field is unique (0x20).

This commit adds database entries for the models. ALSA dice driver supports
them, but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for models based on DICE ASICs specialized by Loud Technologies

LOUD Audio, LLC (formerly known as LOUD Technologies, Inc.) shipped some
models based on DICE ASICs in its Mackie brand. The content of
configuration ROM has a quirk that the value of category field is unique
(0x10).

This commit adds database entries for the models. ALSA dice driver supports
them, but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for models based on DICE ASICs specialized to Weiss Engineering

Weiss Engineering Ltd. shipped some models based on DICE ASICs. The
content of configuration ROM has a quirk that the value of category
field is unique (0x00).

This commit adds database entries for the models. ALSA dice driver supports
them, but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for models based on DICE ASICs specialized to M-Audio

M-Audio shipped some models based on DICE ASICs. The content of
configuration ROM has a quirk that the value of version field in unit
directory is different from the one in TCAT specification (0x000001).

This commit adds database entries for the models. ALSA dice driver supports
them, but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for models based on DICE ASICs with TCAT specification

TC Applied Technologies designed the series of ASIC for audio and music
data transmission in several types of communication bus. It's named as
Digital Interface Communication Engine (DICE). Four ASICs are known in
the series for IEEE 1394 bus; Dice II, TCD2210 (Dice Jr.), TCD2220 (Dice
Mini), and TCD3070 (DiceIII).

The content of configuration ROM in products based on DICE ASICs is
known against specification defined by 1394 Trading Association.

This commit adds database entries for models without any customization by
vendors. In TCAT specification, The value of GUID field is split to four
parts; 24-bit OUI, 8-bit category, 10-bit product ID, and 22-bit serial
number in the order. In the specification, the value of category field is
fixed to 0x04. The root directory includes leaf entries for vendor and
model names. Although the specifier_id field in unit directory differs
depending on vendors, the version field in unit directory is fixed to
0x000001. ALSA dice driver supports them, but expects userspace
application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for models with OXFW970/971 ASICs

Once Oxford Semiconductor designed FW970 and FW971 ASICs as Multi-Channel
Isochronous Streaming FireWire Audio Controller. Some vendors used them
in their products for audio and music units.

The content of configuration ROM has standard layout of 1394 Trading
Association with an additional Dependent Information directory.

This commit adds database entries for the known models. ALSA oxfw
driver supports them, but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for models with Fireworks board module

Echo Audio Corporation designed Fireworks board module. The module is used
by several vendors for models.

The content of configuration ROM in the models s some quirks and against
standard of 1394 Trading Association.

This commit adds database entries for the model. ALSA fireworks driver
supports them but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add database entries for models with ASICs in BeBoB solution

ArchWave AG, formerly known as BridgeCo. AG, designed DM1000, DM1100, and
DM1500 ASICs for BridgeCo. Enhancement BreakOut Box (BeBoB) solution.
They were used for many models shipped by many vendors.

The content of configuration ROM has standard layout of 1394 Trading
Association with an additional Dependent Information directory.

This commit adds database entries for the known models. ALSA bebob
driver supports them, but expects userspace application to control them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: allow parser to expect usage of slash sign in value of property

Although in IEEE 1394 unit function list I have a plan to use slash sign
in name of property, current implementation of parser doesn't allow it.
When parsing current entries in database excluded from parser testing, we
can find usage of slash sign in name of property.

This commit adds slash sign in allow list of the parser for my
convenience.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add parser grammar for IEEE 1394 unit function list

In added IEEE 1394 unit function list, I use custom key to detect unit
entries in node context. Although the list is not widely used in the most
of systemd users, I would like to add parser grammar for testing, by
borrowing a bit time in builders.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

hwdb: add hardware database for unit of IEEE 1394

Current udev rules configures group owner of firewire character device
to video group, corresponding to nodes in IEEE 1394 in below cases:

1.the node with any unit for any minor version of IIDC version 1
  specification defined by 1394 Trading Association
2.the node with any unit for specification defined by Point Grey Research
3.the node with any unit for AV/C device v1.0 defined by 1394 Trading
  Association
4.the node with any unit for vendor-unique protocol defined by 1394
  Trading Association

Nevertheless, case 3 and 4 can cover the node with any unit for audio
function as well. In the cases, it's convenient to assign audio group.

Additionally, some nodes are known to have layout different from
the specification defined by 1394 Trading Association. In the case,
it's required to add rules specific to them.

Furthermore, some nodes have no fields for vendor name and model name in
configuration ROM. In the case, it's required to add entries to hardware
database for users convenience.

For the above reasons, this commit adds rules to use information in
hardware database for known units in IEEE 1394. One database entry
corresponds to one unit. Two types of key are used to match the unit;
customized key from node context, kernel modalias of unit context.
The entry has the type of function, at least. Supplementally, it has
vendor and model names.

For your information, below statements with Python pyparsing module are
expected to parse all of the custom key and module alias in the list:

```
subsystem_prefix = pp.Literal('ieee1394:').suppress()
hex_to_int = lambda a: int(a[0], 16)

node_prefix = pp.Literal('node:').suppress()
prefixed_lower_hex = pp.Combine(pp.Literal('0x') + pp.Word(pp.srange('[a-z0-9]'), exact=6)).setParseAction(hex_to_int)
ven_in_node = pp.dictOf(pp.Literal('ven'), prefixed_lower_hex)
mo_in_node = pp.dictOf(pp.Literal('mo'), prefixed_lower_hex)
unit_in_node = pp.Group(prefixed_lower_hex + pp.Literal(':').suppress() + prefixed_lower_hex)
units_in_node = pp.Group(pp.Literal('units') + pp.ZeroOrMore(pp.Literal('*')).suppress() + unit_in_node + pp.ZeroOrMore(pp.Literal('*')).suppress())
node_parser = subsystem_prefix + node_prefix + ven_in_node + pp.Optional(mo_in_node) + units_in_node

higher_hex = pp.Word(pp.srange('[A-Z0-9]'), exact=8).setParseAction(hex_to_int)
ven_in_unit = pp.dictOf(pp.Literal('ven'), higher_hex)
mo_literal_in_unit = pp.dictOf(pp.Literal('mo'), higher_hex)
mo_in_unit = pp.dictOf(pp.Literal('mo'), higher_hex ^ pp.Literal('*'))
sp_in_unit = pp.dictOf(pp.Literal('sp'), higher_hex)
ver_in_unit = pp.dictOf(pp.Literal('ver'), higher_hex)
unit_parser = subsystem_prefix + ven_in_unit + mo_in_unit + sp_in_unit + ver_in_unit

key_parser = node_parser ^ unit_parser
```

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>

test: check if the unit file fuzzer corpora is up to date

This follows a similar pattern we already have in place for
networkd-related directives.

fuzzer: add a test case for #19178

Merge pull request #19179 from anitazha/buildandtest

test-oomd-util: fix running in mkosi

udev: fix slot based network names on s390

The s390 PCI driver assigns the hotplug slot name from the
function_id attribute of the PCI device using a 8 char hexadecimal
format to match the underlying firmware/hypervisor notation.

Further, there's always a one-to-one mapping between a PCI
function and a hotplug slot, as individual functions can
hot plugged even for multi-function devices.

As the generic matching code will always try to parse the slot
name in /sys/bus/pci/slots as a positive decimal number, either
a wrong value might be produced for ID_NET_NAME_SLOT if
the slot name consists of decimal numbers only, or none at all
if a character in the range from 'a' to 'f' is encountered.

Additionally, the generic code assumes that two interfaces
share a hotplug slot, if they differ only in the function part
of the PCI address. E.g., for an interface with the PCI address
dddd:bb:aa.f, it will match the device to the first slot with
an address dddd:bb:aa. As more than one slot may have this address
for the s390 PCI driver, the wrong slot may be selected.

To resolve this we're adding a new naming schema version with the
flag NAMING_SLOT_FUNCTION_ID, which enables the correct matching
of hotplug slots if the device has an attribute named function_id.
The ID_NET_NAME_SLOT property will only be produced if there's
a file /sys/bus/pci/slots/<slotname> where <slotname> matches
the value of /sys/bus/pci/devices/.../function_id in 8 char
hex notation.

Fixes #19016
See also #19078

Merge pull request #18717 from yuwata/sd-device-monitor-introduce-more-filters

sd-device-monitor: introduce two new filters and use them in dissect-image.c

docs: use current spelling "macOS" not "OS X" etc.

dissect-image: move parent device check into device_is_partition()

Checking parent for enumerated devices is mostly redundant. Just for
safety.

dissect-image: also check devtype in device_is_partition()

This should be mostly redundant. Just for safety.

dissect-image: filter out enumerated or triggered devices without "partition" sysattr

This also adds more filters for device enumerator and monitor.
These newly added filters should be mostly redundant. But this hides
spurious error in sd_device_get_sysattr_value(). See,
https://github.com/systemd/systemd/pull/18684#discussion_r579700977

test: add tests for filters of sd-device-monitor

sd-device-monitor: introduce sd_device_monitor_filter_add_match_parent()

sd-device-enumerator: also move match_parent() to device-util.[ch]

sd-device-monitor: introduce sd_device_monitor_filter_add_match_sysattr()

sd-device-enumerator: move match_sysattr() to device-util.[ch]

It will be used by sd-device-monitor in later commits.

sd-device-monitor: split passes_filter() into two parts

test-oomd-util: fix running in mkosi

When this test is run in mkosi, the previously tested cgroup that we write
xattrs into and the root cgroup are the same.

Since the root cgroup is a live cgroup anyways (vs. the test cgroups which are
remade each time) let's generate the expected preference values from reading
the xattrs instead of assuming it will be NONE.

meson: link with libm for math functions

Fixes this error I got building on F33:
  /usr/bin/ld: test-random-util.p/src_test_test-random-util.c.o: undefined
  reference to symbol 'sqrt@@GLIBC_2.2.5'
  /usr/bin/ld: /usr/lib64/libm.so.6: error adding symbols: DSO missing
  from command line

systemd-notify: Fix return value of --booted

Merge pull request #19175 from keszybz/maybe-unitialized-warning-2

Third batch of fixes and suppressions for maybe-unitialized warnings

resolved: use _cleanup_(gcry_md_closep) in one more place

Documentation says gcry_md_close will ignore a NULL input so should be safe:

https://gnupg.org/documentation/manuals/gcrypt/Working-with-hash-algorithms.html

Makes Coverity happy, follow-up for 248b1e0aa4

CID #1451555

libudev: fix return of udev_monitor_filter_add_match_subsystem_devtype()

Follow-up for 7117842657c0fc5a3446b6fe158615279cf2d650.

sd_device_monitor_filter_add_match_subsystem_devtype() now returns 1 to signify
that something was done, and 0 to signify that nothing was done, but
udev_monitor_filter_add_match_subsystem_devtype() needs to return 0 as documented.

udev_monitor_filter_add_match_tag() is adjusted to match.

This makes gdm start successfully here again.
Before, it would just not boot, with nothing very obvious in the logs:
gdm[1756]: Gdm: GdmDisplay: Session never registered, failing

Replaces #19171.

resolved: avoid passing unitialized variable

The issue was introduced in the refactoring in 775ae35403f8f3c01b7ac13387fe8aac1759993f.
We would pass an initialized value to a helper function. We would only *use*
it if it was initialized. But the mere passing of an unitialized variable is
UB, so let's not do that. This silences a gcc warning.

various: silence gcc warnings

AFAICT, gcc is just being stupid in all those cases.

shared/dissect-image: silence gcc warning

sd-netlink: drop unnecessary forward declaration

backlight: refactor get_max_brightness() to appease gcc

The old code was just fine, but gcc doesn't understand that max_brightness is
initialized. Let's rework it a bit to move some logic to the main function. Now
get_max_brightness() just retrieves and parses the attribute, and the main
function decides what to do with it.

test-device-util: let's verify that we return proper error from log_device_*

sd-device: header needs an include because it uses sd_device type

Merge pull request #19168 from keszybz/nss-resolve-unfoobar

Fix nss-resolve reverse alias lookups

Merge pull request #19169 from keszybz/reenable-maybe-unitialized-warning

Fix a bunch of maybe-unitialized warnings but don't enable the warning yet

logind: Rename kexec reboot flag

Also change error message to be more meanigful. No change in
functionality.

Fixes: 0d96caa5c0

basic/env-util: silence two gcc warnings

cryptsetup: silence gcc maybe-unused warning

Simplify one debug stmt while at it.

systemctl: silence gcc maybe-unused warning

shared/pretty-print: silence gcc warning

gcc was very unhappy for some reason:

[988/1664] Compiling C object systemd-oomd.p/src_oom_oomd.c.o
In file included from ../src/basic/path-util.h:10,
                 from ../src/shared/pretty-print.c:14,
                 from ../src/oom/oomd.c:15:
../src/shared/pretty-print.c: In function ‘conf_files_cat’:
../src/basic/strv.h:123:32: warning: ‘prefixes’ may be used uninitialized [-Wmaybe-uninitialized]
  123 |         for ((s) = (l); (s) && *(s); (s)++)
      |                                ^
In file included from ../src/oom/oomd.c:15:
../src/shared/pretty-print.c:283:16: note: ‘prefixes’ was declared here
  283 |         char **prefixes, **prefix;
      |                ^~~~~~~~
../src/shared/pretty-print.c:305:12: warning: ‘is_collection’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  305 |         if (!is_collection) {
      |            ^
../src/shared/pretty-print.c:301:13: warning: ‘extension’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  301 |         r = conf_files_list_strv(&files, extension, root, 0, (const char* const*) dirs);
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Maybe this is caused by the statis char** variables?

core: silence gcc warning

shared/bus-message-util: silence gcc warning

[1/429] Compiling C object src/shared/libsystemd-shared-248.a.p/bus-message-util.c.o
../src/shared/bus-message-util.c: In function ‘bus_message_read_dns_servers’:
../src/shared/bus-message-util.c:165:21: warning: ‘family’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  165 |                 r = in_addr_full_new(family, &a, port, 0, server_name, dns + n);
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/shared/bus-message-util.c:165:21: warning: ‘port’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../src/shared/bus-message-util.c:165:21: warning: ‘server_name’ may be used uninitialized in this function [-Wmaybe-uninitialized]

The warning would be there despite all the asserts in bus_error_setfv() and
sd_bus_error_set(). So let's add an explicit assert.

shared/conf-parser: fix unitialized variable

Introduced in 4f9ff96a55187927a4164a19df580329f4c6522b.

test-capability: silence gcc warning

[2/3] Compiling C object test-capability.p/src_test_test-capability.c.o
../src/test/test-capability.c: In function ‘main’:
../src/test/test-capability.c:270:12: warning: ‘run_ambient’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  270 |         if (run_ambient)
      |            ^

gcc-11.0.1-0.3.fc34.x86_64

basic/cgroup-util: silence gcc warning about unitialized variable

sd-event: silence gcc's maybe-unitialized warning

[91/180] Compiling C object libsystemd.a.p/src_libsystemd_sd-event_sd-event.c.o
In file included from ../src/basic/macro.h:12,
                 from ../src/basic/alloc-util.h:9,
                 from ../src/libsystemd/sd-event/sd-event.c:11:
../src/libsystemd/sd-event/sd-event.c: In function ‘sd_event_wait’:
../src/fundamental/macro-fundamental.h:86:63: warning: ‘child_min_priority’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   86 |                 UNIQ_T(A, aq) < UNIQ_T(B, bq) ? UNIQ_T(A, aq) : UNIQ_T(B, bq); \
      |                                                               ^
../src/libsystemd/sd-event/sd-event.c:3983:45: note: ‘child_min_priority’ was declared here
 3983 |                 int64_t epoll_min_priority, child_min_priority;
      |                                             ^~~~~~~~~~~~~~~~~~

Alternative to #19159.

varlink: use two local flag variables to silence gcc warning

[59/655] Compiling C object src/shared/libsystemd-shared-248.a.p/varlink.c.o
../src/shared/varlink.c: In function ‘varlink_write’:
../src/shared/varlink.c:459:12: warning: ‘n’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  459 |         if (n < 0) {
      |            ^
../src/shared/varlink.c: In function ‘varlink_process’:
../src/shared/varlink.c:541:12: warning: ‘n’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  541 |         if (n < 0) {
      |            ^
../src/shared/varlink.c:486:17: note: ‘n’ was declared here
  486 |         ssize_t n;
      |                 ^

man: split the description of sd_bus_error_set()

It was one giant all of text in pseudo-random order. Let's split it into
paragraphs talk about one subject each.

And unfortunately, the description of what happens when the error is not
set was not correct. In general, various functions treat 0/NULL as
not-an-error, and return 0.

sd-bus: add asserts showing that sd_bus_error_setf() returns negative

(when name is specified).

sd-bus: add assert to tell the compiler that the error code is positive

I was hoping it would help with the following gcc warning:
[35/657] Compiling C object src/shared/libsystemd-shared-248.a.p/bus-message-util.c.o
../src/shared/bus-message-util.c: In function ‘bus_message_read_dns_servers’:
../src/shared/bus-message-util.c:165:21: warning: ‘family’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  165 |                 r = in_addr_full_new(family, &a, port, 0, server_name, dns + n);
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/shared/bus-message-util.c:165:21: warning: ‘port’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../src/shared/bus-message-util.c:165:21: warning: ‘server_name’ may be used uninitialized in this function [-Wmaybe-uninitialized]

It actually doesn't, but the compiler has a point here: the code is specified
in sd_bus_error_map[], and it has no way of knowning that we want it to be a
positive value.

I think this should be an assert, because if this assumption fails, a
programming error has occured, something that'd want to catch.

basic/fileio: silence gcc's maybe-unitialized warning

[11/657] Compiling C object src/basic/libbasic.a.p/fileio.c.o
../src/basic/fileio.c: In function ‘write_string_stream_ts’:
../src/basic/fileio.c:167:21: warning: ‘fd’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  167 |                 if (futimens(fd, twice) < 0)
      |                     ^~~~~~~~~~~~~~~~~~~

basic/socket-util: add hint to silence gcc's maybe-unitialized warning

[59/1551] Compiling C object src/basic/libbasic.a.p/socket-util.c.o
../src/basic/socket-util.c: In function ‘socket_get_mtu’:
../src/basic/socket-util.c:1393:16: warning: ‘mtu’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 1393 |         *ret = (size_t) mtu;
      |                ^~~~~~~~~~~~

resolved: drop unnecessary {}

nss-resolve: define variables in the body

Same motivation as in the parent commit: let's define variables later, ideally
right when they are first initialized, so it's easier to figure out that they
are properly initialized.

error_id and r_tuple* were previously initialized, but I don't see why they
would need to be.

No functional change intended.

nss-resolve: fix parsing of io.systemd.Resolve.ResolveAddress reply

Since the switch to varlink in 0c73f4f075a2d23f7cabe708b589f19f4bbbec37, the
code wasn't functional. The JSON_VARIANT_UNSIGNED/JSON_VARIANT_STRING mismatch
meant that we'd reject any reply. Once past that, the code would use
unitialized 'c' and 'n' variables, so it's lucky we never got that far ;)

With -Wmaybe-unitialized, gcc would warn.

I think that declaring the huge list of local variables with very short names
at the top of the function was making it harder to understand what is going on
in the function. So let's rename the variables a bit, and initialize them upon
declaration if possible.

$ build/test-nss-hosts resolve 1.1.1.1 1.0.0.1 10.38.5.41
======== resolve ========
_nss_resolve_gethostbyaddr2_r("1.1.1.1") → status=NSS_STATUS_SUCCESS
                   errno=999/--- h_errno=0/Resolver Error 0 (no error) ttl=0
        "one.one.one.one"
        AF_INET 1.1.1.1

_nss_resolve_gethostbyaddr_r("1.1.1.1") → status=NSS_STATUS_SUCCESS
                   errno=999/--- h_errno=0/Resolver Error 0 (no error)
        "one.one.one.one"
        AF_INET 1.1.1.1

_nss_resolve_gethostbyaddr2_r("1.0.0.1") → status=NSS_STATUS_SUCCESS
                   errno=999/--- h_errno=0/Resolver Error 0 (no error) ttl=0
        "one.one.one.one"
        AF_INET 1.0.0.1

_nss_resolve_gethostbyaddr_r("1.0.0.1") → status=NSS_STATUS_SUCCESS
                   errno=999/--- h_errno=0/Resolver Error 0 (no error)
        "one.one.one.one"
        AF_INET 1.0.0.1

_nss_resolve_gethostbyaddr2_r("10.38.5.41") → status=NSS_STATUS_SUCCESS
                   errno=999/--- h_errno=0/Resolver Error 0 (no error) ttl=0
        "squid.redhat.com"
        alias "squid.corp.redhat.com"
        alias "squid2.corp.redhat.com"
        alias "squid3.corp.redhat.com"
        alias "squid4.corp.redhat.com"
        alias "squid5.corp.redhat.com"
        AF_INET 10.38.5.41

_nss_resolve_gethostbyaddr_r("10.38.5.41") → status=NSS_STATUS_SUCCESS
                   errno=999/--- h_errno=0/Resolver Error 0 (no error)
        "squid.redhat.com"
        alias "squid.corp.redhat.com"
        alias "squid2.corp.redhat.com"
        alias "squid3.corp.redhat.com"
        alias "squid4.corp.redhat.com"
        alias "squid5.corp.redhat.com"
        AF_INET 10.38.5.41

(I have 10.38.5.41 squid.redhat.com squid.corp.redhat.com squid2.corp.redhat.com squid3.corp.redhat.com squid4.corp.redhat.com squid5.corp.redhat.com
in /etc/hosts for testing.)

portabled: add --extension parameter for layered images support

Add an --extension parameter to portablectl, and new DBUS methods
to attach/detach/reattach/inspect.
Allows to append separate images on top of the root directory (os-release
will be searched in there) and mount the images using an overlay-like
setup (unit files will be searched in there) using the new ExtensionImages
service option.

gcrypt: do not ignore return values

Check the return code from gcrypt's functions. In some
cases just log, as it shoulnd't really happen.

Fixes various Coverity issues:

CID #1444702
CID #1444704
CID #1444706
CID #1444711
CID #1444712
CID #1444713

rpm: when disabling a unit, do not complain if systemd is not running

$ sudo dnf remove --installroot=/var/tmp/img1 systemd-networkd
...
  Running scriptlet: systemd-networkd-248~rc4-4.fc32.x86_64      1/1
Removed /etc/systemd/system/multi-user.target.wants/systemd-networkd.service.
Removed /etc/systemd/system/sockets.target.wants/systemd-networkd.socket.
Removed /etc/systemd/system/dbus-org.freedesktop.network1.service.
Removed /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service.
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

(Another option would be make --now do nothing if systemd is not running.
But I think that's not too good. 'disable --now' doing nothing would be OK,
since if systemd is not running, the service is not running either, so we are
in the desired state. But that argument doesn't work for 'enable --now'. And
accepting 'disable --now' but not 'enable --now' seems overly complex. So I
think it is better to make the scriptlet handle this case explicitly.)

Also, let's reindent the file to 4 spaces. Very deeply nested scriptlets are
harder to read, and the triggers file is indented to 4 spaces already.

resolved.conf: Add hostnames for default DNS servers

logind: Add new flag for kexec reboot

Add new flag to allow kexec reboot if kernel is already loaded.

Merge pull request #19109 from poettering/resolved-transaction-log-tweaks

resolved: minor tweaks to transaction logic and logging

shared: add new IMAGE_VERSION=/IMAGE_ID= field to /etc/os-release

This specifes two new optional fields for /etc/os-release:
IMAGE_VERSION= and IMAGE_ID= that are supposed to identify the image of
the current booted system by name and version.

This is inspired by the versioning stuff in
https://github.com/systemd/mkosi/pull/683.

In environments where pre-built images are installed and updated as a
whole the existing os-release version/distro identifier are not
sufficient to describe the system's version, as they describe only the
distro an image is built from, but not the image itself, even if that
image is deployed many times on many systems, and even if that image
contains more resources than just the RPMs/DEBs.

In particular, "mkosi" is a tool for building disk images based on
distro RPMs with additional resources dropped in. The combination of all
of these together with their versions should also carry an identifier
and version, and that's what IMAGE_VERSION= and IMAGE_ID= is supposed to
be.

Merge pull request #19064 from yuwata/resolve-fix-cache-19049

resolve: several trivial cleanups

udevd: don't kill worker in manager_kill_workers when it's running

If worker is running, kill worker may lead uevent unprocessed.

Merge pull request #18990 from yuwata/network-dhcpv6-use-domains

network: also introduce UseDomains= for [DHCPv6] section

Merge pull request #19101 from poettering/mount-util-fixes

Make recursive bind remounting handle failures gracefully

dissect: make the --image= switch of our various tools honour Verity data

This adds simple Verity support to
mount_image_privately_interactively(): we dicover the verity metadata
and use it.

Merge pull request #18989 from yuwata/ordered-set-put-strdup

ordered-set: make ordered_set_put_strdup() allocate OrderedSet object

repart: make sure CopyFiles= works with a / suffixed path

If we define a partition with CopyFiles=/efi/ this should just work.
However it previously didn't because basename() would return the
trailing slash.

Let's fix this by moving things to path_extract_{directory|filename}()

machine-id-setup: support --image= mode

Merge pull request #18971 from poettering/sysusers-creds

let's read LoadCredentials=/SetCredentials= style cred in sysusers/firstboot and when asking for passwords

Merge pull request #18982 from keszybz/test-nss-users

Add a new test for user/group resolution in nss modules

Merge pull request #18958 from poettering/dissect-no-root

dissect-image: support images without rootfs but with /usr partition + support simple partition versioning via strverscmp() on part label

compress: support streaming lz4 without full input mmap

The advantage of stream compression is keeping a low memory profile,
but the lz4 stream compressor usage mmaps the whole file in memory.

Change it to read bits by bits, like the other stream compression
helpers.

Merge pull request #18886 from anitazha/shutdownconsole

logging shutdown to /dev/console

Merge pull request #18850 from yuwata/sd-device-monitor-cleanups

sd-device-monitor: trivial cleanups

Introduce ExitType

Merge pull request #18777 from yuwata/network-set-ifname-to-engines

network: set ifname to dhcp4 client or friends

Merge pull request #19157 from keszybz/read-medium-sized-virtual-file

basic/fileio: fix reading of not-too-small virtual files

NEWS: prep release date

test-fileio: test for read_full_virtual_file()

It was already called through other places, but indirectly.
Let's add some direct invocations.

basic/fileio: fix reading of not-too-small virtual files

This code is trying to do two things: when reading a file with working
st.st_size, detect when the file size changes between the fstat() and our
allocation of the buffer based on the returned size, and the subsequent read().
When reading a file without st.st_size, read up to READ_FULL_BYTES_MAX.

But this second scenario was partially broken: we'd start with size = 4095, and
double the size up to three times, i.e. up to 32767. But we want to read up to
READ_FULL_BYTES_MAX.

So let's listentangle the two cases a bit: if a file returns non-zero st._size,
proceed as before. But if we don't know the size, let's immediately allocate
the buffer of maximum size of READ_FULL_BYTES_MAX. I think that allocating 4MB
and 1MB is going to take pretty much the same time as long as the memory is not
written to, so by allocating 1MB, 2MB, and 4MB, we wouldn't really be saving
anything internally, but wasting time on repeated reads, if the file is long
enough.

Also, don't do the seek if we know we're going to return an error immediately
after.

This should fix reading of any files in /proc, which all have size == 0. In
particular, various files read by coredump might be larger than 32767.

What about /sys? The file there return a fake value, usually 4096. So we'll
allocate a small buffer and read that.

Merge pull request #19149 from anitazha/oomdlogging

oomd: make it more clear when a kill happens