Re: [PATCH 1/2] vpn-provider: Implement connmand online state checking

[Jussi Laakkonen <jussi.laakkonen@jolla.com>]

Hi Daniel,

Thanks for the comments. This piece of code has been running in our fork 
for approx. 3 years but that does not mean there wouldn't be any issues 
to fix or to improve.

On 8/17/21 7:55 PM, Daniel Wagner wrote:
> Hi Jussi,
> 
> Just a bunch of small nits.
> 
> On Tue, Aug 17, 2021 at 06:14:42PM +0300, Jussi Laakkonen wrote:
>> +static gboolean do_connect_timeout_function(gpointer data)
>> +{
>> +	DBG("");
>> +
>> +	/*
>> +	 * Keep in main loop if no agents are present yet or if connman is not
>> +	 * yet online
>> +	 */
>> +	if (!connman_agent_get_info(NULL, NULL, NULL) || !connman_online) {
>> +		return G_SOURCE_CONTINUE;
> 
> Doesn't this get the mainloop busy looping?
> 

As far as I can remember this is intentional. This is added to mainloop 
with 1s delay in do_connect_later() for the delayed VPN connect so I 
guess looping with 1s interval is not too busy?

>> +	} else {
> 
> As there is a return above, no need to do a else statement. Makes also
> the indention one less :)

Yep, that cleans up the rest as well a bit.

> 
>> +		struct vpn_provider_connect_data *cdata = data;
>> +		struct vpn_provider *provider = cdata->provider;
>> +		int err;
>> +
>> +		provider->do_connect_timeout = 0;
>> +		err = __vpn_provider_connect(provider, cdata->msg);
>> +
>> +		if (err < 0 && err != -EINPROGRESS) {
>> +			g_dbus_send_message(cdata->conn,
>> +				__connman_error_failed(cdata->msg, -err));
>> +			cdata->msg = NULL;
>> +		}
>> +
>> +		return G_SOURCE_REMOVE;
>> +	}
>> +}
> 
> [...]
> 
>> +static void do_connect_later(struct vpn_provider *provider,
>> +					DBusConnection *conn, DBusMessage *msg)
>> +{
>> +	struct vpn_provider_connect_data *cdata =
>> +		g_try_new0(struct vpn_provider_connect_data, 1);
> 
> Do a g_new0() instead of a g_try_new0().

Right, will do this was following the old coding style :).

> 
>> +
>> +	cdata->conn = dbus_connection_ref(conn);
>> +	cdata->msg = dbus_message_ref(msg);
>> +	cdata->provider = provider;
>> +
>> +	if (provider->do_connect_timeout)
>> +		g_source_remove(provider->do_connect_timeout);
>> +
>> +	provider->do_connect_timeout =
>> +		g_timeout_add_seconds_full(G_PRIORITY_DEFAULT, 1,
>> +					do_connect_timeout_function, cdata,
>> +					do_connect_timeout_free);
>> +}
>> +
> 
> [...]
> 
>> +static gboolean run_get_connman_state(gpointer user_data)
>> +{
>> +	const char *path = "/";
>> +	const char *method = "GetProperties";
>> +	gboolean rval = FALSE;
>> +
>> +	DBusMessage *msg = NULL;
>> +	DBusPendingCall *call = NULL;
>> +
>> +	DBG("");
>> +
>> +	msg = dbus_message_new_method_call(CONNMAN_SERVICE, path,
>> +		CONNMAN_MANAGER_INTERFACE, method);
>> +
>> +	if (!msg)
>> +		goto out;
>> +
>> +	if (!(rval = g_dbus_send_message_with_reply(connection, msg,
>> +		&call, -1))) {
> 
> Move the 'rval = ...' outside the if condition.

Thanks for pointing that out. It looks indeed messy.

> 
>> +		connman_error("Cannot call %s on %s",
>> +			method, CONNMAN_MANAGER_INTERFACE);
>> +		goto out;
>> +	}
>> +
>> +	if (!call) {
>> +		connman_error("set pending call failed");
>> +		goto error;
>> +	}
>> +
>> +	if (!dbus_pending_call_set_notify(call, get_connman_state_reply,
>> +		NULL, NULL)) {
>> +		connman_error("set notify to pending call failed");
>> +		goto error;
>> +	}
>> +
>> +out:
>> +	if (msg)
>> +		dbus_message_unref(msg);
>> +
>> +	/* In case sending was success, unset timeout function id */
>> +	if (rval) {
>> +		DBG("unsetting get_connman_state_timeout id");
>> +		get_connman_state_timeout = 0;
>> +	}
>> +
>> +	/* Return FALSE in case of success to remove from main event loop */
>> +	return !rval;
>> +
>> +error:
>> +	if (call)
>> +		dbus_pending_call_unref(call);
>> +
>> +	rval = G_SOURCE_REMOVE;
> 
> This looks wrong. Shouldn't this be either TRUE or FALSE?
> 

Hm, as a return from a GSourceFunc G_SOURCE_{REMOVE,CONTINUE} is 
documented to be a more memorable name. But I think as well that in this 
case use of those as mixed, in addition to the comment, just creates 
more confusion. Yeah, maybe it is better to use here that as clear 
TRUE/FALSE.

>> +	goto out;
> 
> Please try to avoid jumping up again. Forward goto's are easy to read
> but the backwards one tend to be hard to grasp (at least for me).
> 

Ouch, that indeed looks a bit messy, hah. I'll refactor that a lot. 
There seems to be indentation refactoring needed as well.

I'll send v2 today at some point.

Cheers,
  Jussi