Re: [PATCH 2/2] hostname: Fix "BlueZ 5.XX" adapter name on startup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



H Bastien,

On Wed, Sep 20, 2017 at 7:59 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Bastien,
>
>>>> The hostname plugin listens to property changes from systemd-
>>>> hostnamed
>>>> but doesn't fetch initial values. This means that unless the
>>>> PrettyHostname or StaticHostname changes, the default adapter will
>>>> be
>>>> called "BlueZ 5.XX" matching the version number.
>>>>
>>>> This is the case since the hostname plugin replaced the adaptername
>>>> plugin in 2012.
>>>>
>>>> Fetch the initial values for PrettyHostname,StaticHostname and
>>>> Chassis when the plugin is initiated, so as to make the values
>>>> available for adapter setup.
>>>> ---
>>>> plugins/hostname.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/plugins/hostname.c b/plugins/hostname.c
>>>> index f876d0afb..db9187378 100644
>>>> --- a/plugins/hostname.c
>>>> +++ b/plugins/hostname.c
>>>> @@ -307,6 +307,10 @@ static int hostname_init(void)
>>>>             hostname_proxy = NULL;
>>>>             g_dbus_client_unref(hostname_client);
>>>>             hostname_client = NULL;
>>>> +   } else {
>>>>+           g_dbus_proxy_refresh_property(hostname_proxy,
>>>> "PrettyHostname");
>>>> +           g_dbus_proxy_refresh_property(hostname_proxy,
>>>> "StaticHostname");
>>>> +           g_dbus_proxy_refresh_property(hostname_proxy,
>>>> "Chassis");
>>>>     }
>>>
>>> I am 100% certain that I tested this since this would be a really
>>> dumb plugin otherwise.
>>
>> You don't say ;)
>>
>>> However is it possible that when calling GetManagedObjects the
>>> values are not returned correctly?
>>
>> get_managed_objects() in gdbus/client.c is never called for this
>> GDBusClient.

I guess this can only occur if the bus name does not exist, perhaps it
has not been activated yet, that would explain why calling refresh
would work since that activate the bus name. I wonder if GetNameOwner
is not enough to activate a service? Well perhaps we should use
StartServiceByName then but it doesn't return the bus id so it only
works if the service has activated since we have subscribed to
NameOwnerChanged but in case it is already running we still have to
call GetNameOwner. Btw is this running with dbus-daemon or the new
dbus-broker? Perhaps the later doesn't active things in the same way
dbus-daemon would.


> Hmmm, you should either come via service_connect callback or when setting the proxy handlers. Seems setting the property watch is not triggering the initial GetManagedObjects. And most likely the service_connect is not triggered correctly either. Something is fishy here and it is too long ago that I wrote that code to remember. Maybe we changed something and accidentally broke some expected behavior.
>
> Maybe Luiz and Johan can have a look at this as well, but I have the feeling this should be a fix in the gdbus code.gdbus
>
> Regards
>
> Marcel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" inlinux-bluetooth" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux