[libvirt] [libvirt-glib 1/4] config: Implement gvir_config_domain_graphics_spice_set_listen

Michal Privoznik mprivozn at redhat.com
Tue Sep 25 13:04:47 UTC 2012


On 25.09.2012 14:47, Christophe Fergeau wrote:
> On Tue, Sep 25, 2012 at 02:07:39PM +0200, Michal Privoznik wrote:
> Hey,
> 
>> libvirt supports listen on IP address or a network and I think we need
>> to distinguish these.
> 
> As I understand it, to listen on an IP address or a network, you'd use a
> <listen> child node to the <graphics> node. This patch sets the 'listen'
> attribute on the <graphics> node, which is only about listening on an IP
> address if I didn't miss anything (?).
> 

No you didn't.

> <listen> nodes would be handled in a separate class, but there could
> indeed be an ambiguity between a setter for an object of this type, and
> this API.

Yeah, this is what I had in mind. So if we ever add support for <listen>
child elements we may wish _set_listen to be reserved just for this case:

void
gvir_config_domain_graphics_spice_set_listen(GVirConfigDomainGraphicsSpice *graphics,
                                             GList *listen);

Same scenario is already happening for gvir_config_domain_set_devices().

> 
>> s/gvir_config_domain_graphics_spice_set_listen/gvir_config_domain_graphics_spice_set_listen_ip/
>> maybe?
> 
> It seems it's not necessarily an IP address but this can be a hostname if
> the .rng is to be trusted. I had in the back of my mind the possibility of
> adding _set_listen_address which accepts a GInetAddress or something like
> that (just vague thoughts, I don't have a clear idea about that ;). So
> maybe _set_listen_str would work to avoid the ambiguity? Though as I write
> this mail, this looks weird too...

what about

_listen_address(GVirConfigDomainGraphicsSpice *, const char *addr);

with @addr being either IP or hostname (in fact anything that is acceptable for libvirt)?

> 
> Christophe
> 




More information about the libvir-list mailing list