Return-Path: <nalin@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by krbdev.mit.edu (Postfix) with ESMTP id C11043DC44 for <rt@krbdev.mit.edu>; Thu,  1 Jul 2010 14:06:25 -0400 (EDT)
Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o61I6OXr020687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <rt@krbdev.mit.edu>; Thu, 1 Jul 2010 14:06:25 -0400
Received: from blade.bos.redhat.com (blade.bos.redhat.com [10.16.0.23]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o61I6OVj028343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <rt@krbdev.mit.edu>; Thu, 1 Jul 2010 14:06:24 -0400
Received: from blade.bos.redhat.com (blade.bos.redhat.com [127.0.0.1]) by blade.bos.redhat.com (8.14.4/8.14.3) with ESMTP id o61I6NIp006251 for <rt@krbdev.mit.edu>; Thu, 1 Jul 2010 14:06:23 -0400
Received: (from nalin@localhost) by blade.bos.redhat.com (8.14.4/8.14.4/Submit) id o61I6NDZ006249 for rt@krbdev.mit.edu; Thu, 1 Jul 2010 14:06:23 -0400
Date: Thu, 1 Jul 2010 14:06:23 -0400
From: Nalin Dahyabhai <nalin@redhat.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #6686] IPv6 support for kprop and kpropd
Message-ID: <20100701180623.GA4305@redhat.com>
References: <rt-6686@krbdev.mit.edu> <rt-6686-32979.9.73057777560825@krbdev.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <rt-6686-32979.9.73057777560825@krbdev.mit.edu>
Organization: Red Hat, Inc.
X-Disclaimer: I am not a spokesmodel.  Views expressed are my own.
X-Key-ID: 78688BF5
X-Key-Fingerprint: 60BC AD87 AF51 3A00 8C99  0388 379B CE57 7868 8BF5
User-Agent: Mutt/1.5.20 (2009-12-10)
X-Scanned-BY: MIMEDefang 2.67 on 10.5.11.21
RT-Send-Cc: 
X-RT-Original-Encoding: us-ascii
Content-Length: 603

On Thu, Jul 01, 2010 at 12:42:12PM -0400, Greg Hudson via RT wrote:
> Opening two listener sockets in kpropd is more difficult than I expected, 
> because of the complicated iprop logic.  So I'm committing a variation of 
> your patch.
> 
> Why did you add AI_V4MAPPED to hints in the first getaddrinfo query?

It's more or less a leftover.  It didn't actually have any effect on my
test machine, but it puts that call to getaddrinfo() more in line with
the behavior glibc follows when the hints structure is NULL (which is to
behave as if the supplied flags were (AI_V4MAPPED | AI_ADDRCONFIG)).

Nalin