[Kde-hardware-devel] Solid::Control not finding local loopback

David Hubner hubnerd at ntlworld.com
Mon Dec 21 22:21:45 CET 2009


On 21/12/2009 12:11, Will Stephenson wrote:
> On Friday 18 December 2009 00:55:39 David Hubner wrote:
>    
>> Is this because networkmanager does not provide information on the loopback
>>   device though the dbus interface?
>>      
> That's correct - AFAIK it was never interesting to me the networkmanager folks
> because our main networking priority is getting laptop users on the internet.
>
>    
>> I can provide a patch for this problem, i am just wondering what the
>> situation on the subject is? :)
>>      
> What's the use case for adding it?  I can see the completeness angle, but I
> don't want us to add code without good reason, that would make the
> NetworkManager backend (for example) a hybrid of NM's view of the world and
> the kernel's, requiring filtering to avoid confusing NM with synthetic
> loopback device unique identifiers.
>
>
>    

Its just a case of a consistent API and checking to see if the local 
loopback is active, to allow the local loopback to be a device of the 
type Solid::DeviceInterface::NetworkInterface but not providing any 
information on the "device" in Solid::Control::* could cause problems 
with people getting the udi from the base libs and using that in 
Solid::Control. I am not sure if HAL will work without local loopback ( 
other backends might work without local loopback )  but checking to see 
if the local lookback is active/present would also be helpful. It would 
probably be possible to check for "lo" in NetworkInterface devices, 
therefore being valid, but it seems a slight work around.

>> I am using 4.3.4 not 4.4 beta so if this is fixed or if this has been
>> talked about i am sorry :)
>>      
> You're the first one to bring it up :)
>
> Will
> _______________________________________________
> Kde-hardware-devel mailing list
> Kde-hardware-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>
>    



More information about the Kde-hardware-devel mailing list