Hi Dave,
----- Original Message -----
> Hi,
>
> I have been looking into the the last two (known) TODOs for IPv6 on my list:
>
> libpcp_pmda:
>
> pmdaConnect() in open.c calls __pmdaOpenInet() or __pmdaOpenUnix() depending
> on the value of the e_io field of the supplied pmdaInterface. The approach
> we have been taking to pcp daemons, in keeping with ipv6+inet as a
> transitional situation, is that they should listen on both inet and ipv6
> simultaneously. It would be easy to add support to the pmdaInterface type
> for more than one open 'in_fd', similar to what has been added in
> src/libpcp/src/secureserver.c. When pmdaInet is configured with
> e_io==pmdaInet, then both an inet and ipv6 socket would be opened.
>
> Technically, this seems reasonable to me. My main concern would be that
> pmdaInet and __pmdaOpenInet() would become somewhat misnamed. Options are to
> a) not worry about it, b) rename these items c) add the new behaviour and
> appropriately named API extensions to pmda interface version 6, leaving the
> previous versions alone.
>
> Some guidance here would be appreciated.
>
The PMDA/PMCD relationship is quite a bit different to the client/pmcd
relationship - its one-to-one (noone else will be communicating on this
channel) and is much more controlled. So, I don't think opening ports
for both ipv6 and inet is warranted in the PMDA case, and this should
simplify things. Back-compatibility is required, and this ipv6 option
should be available transparently to all PMDAs that support sockets.
So, the pmcd.conf parsing should be extended to have an "ipv6" style of
socket (alongside unix and inet - start from pmcd/src/config.c line 680
or so), and this should be propagated around including the spots you've
listed above. Ultimately, it should be an ./Install-time decision for
an admin to make, should they choose to go with the socket connection
option for any given PMDA.
> src/pmdas/trace:
>
>
> This component appears to have a listening socket for control purposes, in
> addition to the one obtained for libpcp_pmda for communicating with the
> pmcd. It seems reasonable the IPv6 connections should also be accepted here.
> Any thoughts?
Yeah, this PMDA really needs to be totally rewritten. In the new world order
it should not listen for network traffic at all, IMO, and should acquire lots
of knowledge about how to export the new event metric type, how to setup some
parent/child event relationships, how to assign unique ids to events, and all
sorts of other useful stuff it lacks currently. Almost certainly it should be
deferring to some underlying tracing technology like dyninst/stap/dtrace/lttng
for the application instrumentation side of things (which would remove all of
the socket code you've found), and focus on building the higher level concepts
on top of one/more of those lower level toolkits.
As such, I wouldn't worry about fixing this code up for IPv6 - hopefully it'll
go the way of the dodo.
cheers.
--
Nathan
|