| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
For write there is no such a hack either. The property-info table
should describe whether to skip a property or not.
|
|
|
|
|
|
| |
Do not have multiple ways of expressing a certain thing. There is
a way how to express that the parser shouldn't check for keys, and
that is via the parse-information. No extra hacks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rework this to have a value "parser_no_check_key" so that:
- the default value for this is FALSE, so that we don't need to
explicitly set it in @parse_infos to only get the default.
Contrary to check_for_key.
- check_for_key only had meaning when also "parser" was set.
That means, the value was really "pip->parser && pip->check_for_key".
That came from the fact, that orginally this was tracked as
key_parsers array, which had "parser" always set.
That is confusing, don't do that. The field "parser_no_check_key"
has it's meaning, regardless of whether "parser" is set.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For one, these functions are not often needed. No need to define them in the
"nm-macros-internal.h" header, which is included everywhere. Move them to
"nm-shared-utils.h", which must be explicitly included.
Also, these functions are usually not called directly, but by passing their
function pointer to a sort function or similar. There is no point in having
defined in the header file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Splitting keyfile handling in two "reader.c" and "writer.c" files
is not helpful. What is most interesting, is to see how property XYZ
is serialized to keyfile, and to verify that the parser does the
inverse. For that, it's easier if both the write_xzy() and parse_xyz()
function are beside each other, and not split accross files.
The more important reason is, that both reader and writer have their
separate handler arrays, for special handling of certain properties:
@key_parsers and @key_writers. These two should not be separate but will
be merged. Since they reference static functions, these functions must
all be in the same source file (unless, we put them into headers, which
would be unnecessary complex).
No code was changed, only moved.
|
|
|
|
|
| |
I am going to merge the files for keyfile handling in libnm-core.
There is a reason for that, I'll tell you next.
|
|
|
|
|
|
|
|
|
| |
The key_writers array is searched by matching the @key during
write_setting_value(). Note how write_setting_value() is called
by nm_connection_for_each_setting_value(), thus, @key is the name
of a GObject property for NMSettingIP4Config. But NMSettingIP4Config
has no property names "address-labels". Hence, this was unused
since introducing libnm-core (which never had this internal property).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this, parsing the properties address/route (for both IPv4/IPv6)
has a runtime complexity of O(n*ln(n)).
Previously, parsing these properties was O(1), but the constant factor
was very high because for each address/route-ipv4/ipv6 combination we would
search about 2*1001 times whether there is a matching value.
Now the runtime complexity is O(n*ln(n)) for each of these 4 properties
where n is the number of entries in the keyfile.
Also note, that we only have 4 properties for which the parsing has
this complexity. Hence, parsing the entire keyfile is O(n) + 4*O(n*ln(n))
which is still O(n*ln(n)) not only to parse one the addresses/routes,
but to parse the entire keyfile.
Now, the number of supported addresses/routes is no longer limited
to 1000 (as before). Now we would accept all keys up from 0 up to
G_MAXINT32.
Like before, indexes will be automatically adjusted and gaps in the
numbering are accepted. That is convenient, if the user edits the
keyfile manually and deletes some lines. And we anyway must not change
behavior.
$ multitime -n 200 -s 0 ./src/settings/plugins/keyfile/tests/test-keyfile
# build with -O2
# before:
Mean Std.Dev. Min Median Max
real 0.115+/-0.0000 0.005 0.108 0.115 0.143
user 0.109+/-0.0000 0.005 0.099 0.109 0.132
sys 0.005+/-0.0000 0.002 0.000 0.005 0.013
# after:
Mean Std.Dev. Min Median Max
real 0.334+/-0.0000 0.034 0.300 0.333 0.790
user 0.322+/-0.0000 0.011 0.291 0.323 0.358
sys 0.008+/-0.0000 0.002 0.002 0.008 0.016
|
|
|
|
|
|
| |
Keyfile supports both route*/address* and routes*/addresses*
fields at the same time. Extend the tests, that they are read
all as expected.
|
| |
|
|
|
|
| |
Fixes: 04df4edf48e55478d0f360ea566f5f398aa76268
|
| |
|
|\
| |
| |
| | |
https://github.com/NetworkManager/NetworkManager/pull/91
|
| |
| |
| |
| |
| |
| |
| |
| | |
During _new_active_connection() we just create the NMActiveConnection
instance to proceed with authorization. The caller might not even
authorize, so we must not touch the device yet.
Do that only later.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Often, functions perform a series of steps, and when they fail,
they bail out. It's simpler if the code is structured that way,
so you can read it from top to bottom and whenever something is
wrong, either return directly (or goto a cleanup label at the
bottom).
|
| |
| |
| |
| |
| |
| | |
From the D-Bus layer, no specific-object is represented by "/". We
should early on normalize such values to NULL, and not expect or
handle them later (like during _new_active_connection()).
|
| |
| |
| |
| |
| |
| |
| |
| | |
Merge _new_vpn_active_connection() into _new_active_connection(). It was the
only caller, and it is simpler to have all the code visible at one place.
That also shows, that the device argument is ignored and not handled.
Ensure that no device is specified for VPN type activations.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
and related
Also, in _add_and_activate_auth_done(), always steal the connection
from active's user-data. Otherwise, the lifetime of the connection
is extended until active gets destroyed. For example, if we would leak
active, we would also leak connection that way.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
existing activations
- pass is-vpn to _new_active_connection(). It is confusing that _new_active_connection()
would re-determine whether a connection is a VPN type, although that was already
established previously. The confusing part is: will they come to the
same result? Why? What if not?
Instead pass it as argument and assert that we got it right.
- the check for existing connections should look whether there is an existing
active connection of type NMVpnConnection. Instead, what matters is,
- do we have a connection of type VPN (otherwise, don't even bother
to search for existing-ac)
- is the connection already active?
Checking whether the connection is already active, and ask backwards
whether it's of type NMVpnConnection is odd, maybe even wrong in
some cases.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- there are only two callers of validate_activation_request(). One of them,
might already lookup the device before calling the validate function.
Safe to looking up again. But this is not only an optimization, more importantly,
it feels odd to first lookup a device, and then later look it up again. Are
we guaranteed to use the same path? Why? Just avoid that question.
- re-order some error checking for missing device, so that it is clearer.
- use cleanup attribute to handle return value and drop the "goto error".
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
It can be easily verified, that these assertions should not ever fail.
Disable in production builds.
|
| |
| |
| |
| |
| | |
- use nm_assert() for something that ~really~ always should be given.
- use nm_streq0() and nm_clear_g_free().
|
| |
| |
| |
| |
| |
| |
| |
| | |
NMDBusObject already gets this right, by calling nm_dbus_utils_get_property(),
which calls g_dbus_gvalue_to_gvariant(), which correctly converts NULL
object paths to "/".
We already rely on that elsewhere. No need for this workaround.
|
| | |
|
| | |
|
| |
| |
| |
| | |
properties
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
| |
_dbus_new_proxy_cb()
In the loop, we invoke callbacks. What the callbacks do, is out of control
of NMAuthManager. For example, they could cancel or schedule new
requests. Especially, cancelling invalidate the stored @safe pointer.
Fix that, by always iterate from the start of the list.
Fixes: d0563f0733ed293d67e9a0f6503e28c3f1c08f1b
|
|
|
|
|
|
|
|
| |
In the first loop, the element is removed only when the callback is
executed. The second loop never removes the current element. Use the
for_each macro for both.
Fixes: d0563f0733ed293d67e9a0f6503e28c3f1c08f1b
|
|
|
|
|
|
| |
The list should be empty on disposal.
Fixes: 2ea2df3184d45567fa9c44f5ef90634a779bfb75
|
|
|
|
|
|
|
|
|
| |
Requesting broadcast replies from the DHCP server can be problematic in
filtered environments like some wireless networks. Don't override the
default of using unicast. This matches the behaviour of the external DHCP
clients.
https://github.com/NetworkManager/NetworkManager/pull/93
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The list of calls contains two kinds of elements: (1) calls that don't
need a D-Bus request and are only waiting for the asynchronous
invocation of the callback in an idle function; (2) calls that need a
D-Bus request and are waiting for the D-Bus proxy.
When the proxy creation finishes, only (2) calls must be canceled (if
the creation failed) or started (if the proxy was created).
Fixes: 798b2a7527bddadcec37b48183da313fbc961e45
https://bugzilla.redhat.com/show_bug.cgi?id=1567807
|
|\
| |
| |
| | |
https://github.com/NetworkManager/NetworkManager/pull/90
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of setting multiple callbacks, just let the user set one
vtable with callbacks. Usually, GObject would implement this via
signals. While that makes sense for public objects, for example to
work better with GIR and allow intercepting the signal, this is
overkill for our internal type. And NMPolkitListener already did
not make use of signals, for good reason.
Instead of passing multiple callbacks, must pass one structure with
callback pointers.
Also, extend the signature of the callbacks to always contain a
@self argument and a @user_data.
|