GitLab

Post release version bump.

It seems like coverity cannot deal with g_assert_cmpint and thus
gives us false positives assuming fd could be -1. Use plain
asserts for now. I tried to add a modeling file but that didnt
work int their web interface.

Add checks for the LinkSpeed device property; check we can read it
at all and also that we catch updates.

Properly read the link speed on device updates. Before the device
info was used, but that did not include the full information and
thus the link speed info was bogus. Call the new sysfs function,
bolt_sysfs_read_link_speed, instead of relying on 'info'.

Make the internal sysfs_read_link_speed public so it can be used
to just read the link speed.

In test_str_erase a buffer (buf[256]) is filled with random data.
Later it is duplicated and then erased via bolt_str_erase. As a
check it is compared to 'buf' via g_assert_cmpstr and asserted
that they are not equal.
But if by chance buf[0] is 0, the string is empty and the check
will fail, because there is nothing to erase. Fix that by having
the random data prefixed with "bolt", so that there is always
a valid string to be erased.
Reported-By: Vladimír Čunát <v@cunat.cz>
Reported-By: Sebastien Bacher <seb128@ubuntu.com>

Plug some memory leaks that can occur on errors: failing to get
the bus, or the client. The GTask object was not freed in that
cases.
Reported-By: Marco Trevisan <mail@3v1n0.net>

Check the return value of chmod and emit a debug message if it
fails.

To reduce false positives that are caused by coverity not picking
up assertions.

Add the ability to skip the store failure tests. This is necessary
because they rely on DAC (discretionary access control) of the
file in the store, i.e. the test removes the permission to write
to the file. If the test executor has CAP_DAC_OVERRIDE, it can
bypass that and thus the test wont work.
Consolidate the two store failure checks (label, policy) into an
extra test and skip that if the caller has CAP_DAC_OVERRIDE.
NB: "ninja -C build test" will still show the test as Ok (and the
log will tell it was skipped) because all the tests are executed
individually and the result then will be Ok(skipped=1) which is
not picked up by meson.

If the link speed contains non-zero values for lanes and speed
show the details of rx and tx speed. Insert before authflags to
to be sore that something is before us and something is after
us so we don't need extra logic to know what tree element to
insert ("branch" or "right").

Expose the LinkSpeed dbus property as (linkspeed) including a
getter method. Install the necessary custom wire conversion to
convert the wire representation of BoltLinkSpeed to the struct.

As with BoltExported, add the ability to specify a custom wire
conversion for a given property. Should be called directly after
the D-Bus proxy is created, to make sure the handler is installed
properly.

Expose the link speed of a device (see previous commits) as the
"linkspeed" object and "LinkSpeed" dbus property. Install a
custom wire conversion via the existing BoltConvToWire and
BoltConvFromWire methods provided by BoltLinkSpeed, which will
serialize the struct as "a{su}" on the bus.

Add simple checks for the new BoltLinkSpeed struct and its methods.

Add simple checks for bolt_sysfs_info_for_device including the new
link speed attributes.

Add support for obtaining the link speed for a device via the
existing bolt_sysfs_info_for_device function. If the 'full'
argument is 'TRUE' the new 'linkspeed' member will contain
information about the number lanes and speed of the lanes,
if the corresponding sysfs attributes exist; otherwise they
will be set to '0'.

Add BoltLinkSpeed arguments to device_plug and device_add to be
able to (optionally) specify the link speed for a device.

Instead of using a custom type that is basically a copy of the new
BoltLinkspeed struct, use the latter instead.

Introduce a new BoltLinkSpeed struct that represents the speed of a
link between two thunderbolt/usb4 devices in terms of lanes and the
rate (speed) of the individual lane. See the previous commit for a
description of lane bonding and transfer speeds. The BoltLinkSpeed
struct is registered as a boxed type in the type system so it can
be used as a GObject property. Wire conversion functions are also
provided so it can be used in custom wire conversions and thus be
used with BoltExported.

Recent kernels, starting with commit[1], expose the speed and lanes
of the link between a device and its upstream parent. Lane bonding
itself was first supported by Falcon Ridge (2nd generation) chips.
Current generations (3 and 4) support symmetric connections of up
to 2 lanes and 20 Gb/s per lane. In the future asymmetric links
might be possible.

[1] 91c0c12080d0f40ee7275485221b06b4e1e289e1

Add a new class method that allows to replace the automatically
inferred WireConv for a property with a custom WireConv, by
supplying custom BoltConvToWire and BoltConvFromWire methods.
This is useful for anything where the automatic conversion
would be wrong or no proper automatic conversion exists.

No need to include <gio/gio.h> from the public header.

Add simple check that converting a simple boxed type to the wire
and back via custom conversion functions does indeed work as
expected.

Add support for custom conversions via user provided to_wire and
from_wire conversion functions, which will be used instead of
inferring the conversions from the source and target types.

In the from_wire path, initialize the GValue, if needed, via the
existing helper, directly in bolt_wire_conv_from_wire instead of
all the different individual handlers.

Return the correct value NULL for pointer instead of FALSE.

In order to use them with a future custom conversion type that
will use the wire conversion functions.

The idea behind was that a guard could be active for a process and
when the process dies the guard needs to be removed. This could in
theory happen for a guard of an external process that is does not
have a fifo. In reality this case is impossible, because any guard
that is not created internally, was created via a D-Bus call which
in turn will always create a fifo. The fifo itself is sufficient
to also catch the death of the process even when it happens during
a bolt crash because when bolt re-starts and starts to monitor the
fifo again it will receive the corresponding close event.
Therefore remove process watching from BoltPower.

Check that when we recover guards with an intact fifo that was
closed while we weren't monitoring we get the proper 'released'
signal after it is recovered.

Saves us a few lines.

It is a common task to run a GMainLoop, waiting for an event, with
a set timeout that will abort the loop. In most cases this is also
considered a test failure so the test is aborted with a warning.
Create a helper function to do exactly that.

Check when cleaning up a guard object with an active fifo leaves
the fifo itself as well as the saved guard data intact. Verify
that recovering that guard works and the fifo is still intact as
well.

If the guard is being released but the fifo and thus the watch are
still active, the guard_watch_release function will be called due
to the removal of the watch in the finalizer. In that case the fifo
was not being cleaned up on purpose so we just skip the cleanup.

When recovering guards, ignore all guards that have no fifo. This
should in reality not be any different to what was already being
done, since there are only two different paths that create guards
currently:
  - internal ones, created by boltd itself during initialization
    for domain discovery
  - external ones, created by clients via the D-Bus APi, which
    all will have named pipes

Remove the test that was relying on that code path. The test
for this should be done in the BoltGuard unit tests anyway.

Simple getter exposing the 'fifo' path string, which can be NULL
if there is none.

Simple getter for the 'path' property; NB: will be NULL if guard
is not saved, therefore can be used as proxy for 'is-saved' as
well.

No semantic change, only fix a missing '.