qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Olga Krishtal <okrishtal@parallels.com>
To: Eric Blake <eblake@redhat.com>, Kirk Allan <kallan@suse.com>,
	qemu-devel@nongnu.org
Cc: sw@weilnetz.de, mdroth@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH v3 2/2] qga: win32 implementation of qmp_guest_network_get_interfaces
Date: Wed, 3 Jun 2015 13:11:34 +0300	[thread overview]
Message-ID: <556ED2D6.3010002@parallels.com> (raw)
In-Reply-To: <5568387D.4060808@parallels.com>

On 29/05/15 12:59, Olga Krishtal wrote:
> On 29/05/15 01:56, Eric Blake wrote:
>> On 05/28/2015 12:41 PM, Kirk Allan wrote:
>>> By default, IP addresses and prefixes will be derived from information
>>> obtained by various calls and structures.  IPv4 prefixes can be found
>>> by matching the address to those returned by GetAdaptersInfo. IPv6
>>> prefixes can not be matched this way due to the unpredictable order of
>>> entries.
>>>
>>> In Windows Visa/2008 guests and newer, it is possible to use 
>>> inet_ntop()
>> s/Visa/Vista/
>>
>>> and  OnLinkPrefixLength to get  IPv4 and IPv6 addresses and prefixes.
>> Why the  double  spacing?
>>
>>> Setting –extra-cflags in the build configuration to
>> Again, Unicode mdash looks odd.
>>
>>> ”- D_WIN32_WINNT-0x600 -DWINVER=0x600” or greater enables this 
>>> functionality
>>> for those guests.  Setting –ectra-cflags is not required and if not 
>>> used,
>> s/ectra/extra/
>>
>>> the default approach will be taken.
>>>
>>> Signed-off-by: Kirk Allan <kallan@suse.com>
>>> ---
>>>   qga/commands-win32.c | 292 
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++-
>>>   1 file changed, 290 insertions(+), 2 deletions(-)
>>> +
>>> +static char *guest_inet_ntop(int af, void *cp, char *buf, size_t len)
>>> +{
>>> +#if (_WIN32_WINNT >= 0x0600) && defined(ARCH_x86_64)
>>> +    /* If built for 64 bit Windows Vista/2008 or newer, inet_ntop() is
>>> +     * available for use.  Otherwise, do our best to derive it.
>>> +     */
>>> +    return (char *)InetNtop(af, cp, buf, len);
>>> +#else
>> Are you sure glib doesn't provide some sort of inet_ntop wrapper that
>> you could crib, instead of rolling your own?  And if you must roll your
>> own, do it as a separate patch from the rest of this work, possibly by
>> copying from glibc or other existing implementation (with proper credits
>> to the upstream source), rather than writing it from scratch.
> Agree. Moreover, there is separate functions for inet4 and inet6.
> Pls, look here 
> https://developer.gnome.org/libnm/stable/libnm-nm-utils.html
> Here you can find nm_utils_inet4/6_ntop() description.
>
>>> +    u_char *p;
>> u_char is not a standard typedef; uint8_t is more common.
>>
>
>
Eric, I have looked attentively at glib utils for nm_utils_inet4/6_ntop().
Header to use this function can be found in 
NetworkManager-libnm-devel.XXX.rpm.
It would be difficult to support all its functionality. So, the only 
way, as I see it, to make
out own realization (may be just look at how it was implemented in 
nm-utils.h )

      reply	other threads:[~2015-06-03 10:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-28 18:40 [Qemu-devel] [PATCH v3 0/2] qga: qmp_guest_network_get_interfaces for win32 Kirk Allan
2015-05-28 18:41 ` [Qemu-devel] [PATCH v3 1/2] qga: add additional win32 cflags and libraries Kirk Allan
2015-05-28 22:51   ` Eric Blake
2015-05-29 16:42     ` Kirk Allan
2015-05-28 18:41 ` [Qemu-devel] [PATCH v3 2/2] qga: win32 implementation of qmp_guest_network_get_interfaces Kirk Allan
2015-05-28 20:54   ` Denis V. Lunev
2015-05-29 10:39     ` Olga Krishtal
     [not found]       ` <5568437C020000760012F8A9@prv-mh.provo.novell.com>
2015-06-03 10:19         ` Olga Krishtal
2015-06-03 10:35           ` Olga Krishtal
2015-05-28 22:56   ` Eric Blake
2015-05-29  9:59     ` Olga Krishtal
2015-06-03 10:11       ` Olga Krishtal [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=556ED2D6.3010002@parallels.com \
    --to=okrishtal@parallels.com \
    --cc=eblake@redhat.com \
    --cc=kallan@suse.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sw@weilnetz.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).