Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Steve Dickson]

On 07/26/2011 10:50 AM, Chuck Lever wrote:
> 
> On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote:
> 
>> From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
>>
>> The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and
>> clnttcp6_create and the server functions svcudp6_bufcreate(),
>> svctcp6_create() and svcudp6_create() are not included in the library
>> whe libtirpc is built.
> 
> Are these part of the libtirpc standard API?  I'm not sure why we would need them if, say, Solaris does not support these.
It appears they are not since they are not mentioned the man pages.....
But, at least in the autofs code, they are expected
   https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0

Ian, where else are these routines defined? 

steved

> 
>> Signed-off-by: Steve Dickson <steved-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> src/rpc_soc.c |    4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/rpc_soc.c b/src/rpc_soc.c
>> index c678429..584ac71 100644
>> --- a/src/rpc_soc.c
>> +++ b/src/rpc_soc.c
>> @@ -236,7 +236,7 @@ clnttcp_create(raddr, prog, vers, sockp, sendsz, recvsz)
>>
>> /* IPv6 version of clnt*_*create */
>>
>> -#ifdef INET6_NOT_USED
>> +#ifdef INET6
>>
>> CLIENT *
>> clntudp6_bufcreate(raddr, prog, vers, wait, sockp, sendsz, recvsz)
>> @@ -392,7 +392,7 @@ svcraw_create()
>>
>>
>> /* IPV6 version */
>> -#ifdef INET6_NOT_USED
>> +#ifdef INET6
>> SVCXPRT *
>> svcudp6_bufcreate(fd, sendsz, recvsz)
>> 	int fd;
>> -- 
>> 1.7.6
>>
>>
>> ------------------------------------------------------------------------------
>> Magic Quadrant for Content-Aware Data Loss Prevention
>> Research study explores the data loss prevention market. Includes in-depth
>> analysis on the changes within the DLP market, and the criteria used to
>> evaluate the strengths and weaknesses of these DLP solutions.
>> http://www.accelacomm.com/jaw/sfnl/114/51385063/
>> _______________________________________________
>> Libtirpc-devel mailing list
>> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Ian Kent]

On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote:
> 
> On 07/26/2011 10:50 AM, Chuck Lever wrote:
> > 
> > On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote:
> > 
> >> From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
> >>
> >> The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and
> >> clnttcp6_create and the server functions svcudp6_bufcreate(),
> >> svctcp6_create() and svcudp6_create() are not included in the library
> >> whe libtirpc is built.
> > 
> > Are these part of the libtirpc standard API?  I'm not sure why we would need them if, say, Solaris does not support these.
> It appears they are not since they are not mentioned the man pages.....
> But, at least in the autofs code, they are expected
>    https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0
> 
> Ian, where else are these routines defined? 

Now that I look I can't find the original source tar that was used for
libtirpc, thought I had it.

The story is that long ago when I changed autofs to use libtirpc (to
make it ready for IPv6) I found these functions in the source and they
were (obviously) the IPv6 counterparts for the corresponding IPv4
functions which I was already using, so I used them. It took me quite a
while to realize my code wasn't working and then I found that somewhere
along the line they have been excluded, oops!

If there are to be no IPv6 counterparts for the corresponding IPv4
functions which functions should I use then?

> 
> steved
> 
> > 
> >> Signed-off-by: Steve Dickson <steved-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >> ---
> >> src/rpc_soc.c |    4 ++--
> >> 1 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/rpc_soc.c b/src/rpc_soc.c
> >> index c678429..584ac71 100644
> >> --- a/src/rpc_soc.c
> >> +++ b/src/rpc_soc.c
> >> @@ -236,7 +236,7 @@ clnttcp_create(raddr, prog, vers, sockp, sendsz, recvsz)
> >>
> >> /* IPv6 version of clnt*_*create */
> >>
> >> -#ifdef INET6_NOT_USED
> >> +#ifdef INET6
> >>
> >> CLIENT *
> >> clntudp6_bufcreate(raddr, prog, vers, wait, sockp, sendsz, recvsz)
> >> @@ -392,7 +392,7 @@ svcraw_create()
> >>
> >>
> >> /* IPV6 version */
> >> -#ifdef INET6_NOT_USED
> >> +#ifdef INET6
> >> SVCXPRT *
> >> svcudp6_bufcreate(fd, sendsz, recvsz)
> >> 	int fd;
> >> -- 
> >> 1.7.6
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Magic Quadrant for Content-Aware Data Loss Prevention
> >> Research study explores the data loss prevention market. Includes in-depth
> >> analysis on the changes within the DLP market, and the criteria used to
> >> evaluate the strengths and weaknesses of these DLP solutions.
> >> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> >> _______________________________________________
> >> Libtirpc-devel mailing list
> >> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> >> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
> > 
> 
> ------------------------------------------------------------------------------
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Libtirpc-devel mailing list
> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Ian Kent]

On Wed, 2011-07-27 at 08:57 +0800, Ian Kent wrote:
> On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote:
> > 
> > On 07/26/2011 10:50 AM, Chuck Lever wrote:
> > > 
> > > On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote:
> > > 
> > >> From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
> > >>
> > >> The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and
> > >> clnttcp6_create and the server functions svcudp6_bufcreate(),
> > >> svctcp6_create() and svcudp6_create() are not included in the library
> > >> whe libtirpc is built.
> > > 
> > > Are these part of the libtirpc standard API?  I'm not sure why we would need them if, say, Solaris does not support these.
> > It appears they are not since they are not mentioned the man pages.....
> > But, at least in the autofs code, they are expected
> >    https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0
> > 
> > Ian, where else are these routines defined? 
> 
> Now that I look I can't find the original source tar that was used for
> libtirpc, thought I had it.

Found what I had.

AFAICT what I think was the original source doesn't have any IPv6 code
that I can see.

Worse, these functions were excluded with the "#ifdef INET6_NOT_USED"
macro as far back as libtirpc version 0.1.5 so, my bad, sorry.

> 
> The story is that long ago when I changed autofs to use libtirpc (to
> make it ready for IPv6) I found these functions in the source and they
> were (obviously) the IPv6 counterparts for the corresponding IPv4
> functions which I was already using, so I used them. It took me quite a
> while to realize my code wasn't working and then I found that somewhere
> along the line they have been excluded, oops!
> 
> If there are to be no IPv6 counterparts for the corresponding IPv4
> functions which functions should I use then?

So what can I use?

It seems to me that these functions would be useful for people porting
code that uses the corresponding IPv4 functions so could we define them
please. At some point someone must have had that same idea ....

> 
> > 
> > steved
> > 
> > > 
> > >> Signed-off-by: Steve Dickson <steved-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > >> ---
> > >> src/rpc_soc.c |    4 ++--
> > >> 1 files changed, 2 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/src/rpc_soc.c b/src/rpc_soc.c
> > >> index c678429..584ac71 100644
> > >> --- a/src/rpc_soc.c
> > >> +++ b/src/rpc_soc.c
> > >> @@ -236,7 +236,7 @@ clnttcp_create(raddr, prog, vers, sockp, sendsz, recvsz)
> > >>
> > >> /* IPv6 version of clnt*_*create */
> > >>
> > >> -#ifdef INET6_NOT_USED
> > >> +#ifdef INET6
> > >>
> > >> CLIENT *
> > >> clntudp6_bufcreate(raddr, prog, vers, wait, sockp, sendsz, recvsz)
> > >> @@ -392,7 +392,7 @@ svcraw_create()
> > >>
> > >>
> > >> /* IPV6 version */
> > >> -#ifdef INET6_NOT_USED
> > >> +#ifdef INET6
> > >> SVCXPRT *
> > >> svcudp6_bufcreate(fd, sendsz, recvsz)
> > >> 	int fd;
> > >> -- 
> > >> 1.7.6
> > >>
> > >>
> > >> ------------------------------------------------------------------------------
> > >> Magic Quadrant for Content-Aware Data Loss Prevention
> > >> Research study explores the data loss prevention market. Includes in-depth
> > >> analysis on the changes within the DLP market, and the criteria used to
> > >> evaluate the strengths and weaknesses of these DLP solutions.
> > >> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> > >> _______________________________________________
> > >> Libtirpc-devel mailing list
> > >> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > >> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
> > > 
> > 
> > ------------------------------------------------------------------------------
> > Got Input?   Slashdot Needs You.
> > Take our quick survey online.  Come on, we don't ask for help often.
> > Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> > http://p.sf.net/sfu/slashdot-survey
> > _______________________________________________
> > Libtirpc-devel mailing list
> > Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Ian Kent]

On Wed, 2011-07-27 at 09:23 +0800, Ian Kent wrote:
> On Wed, 2011-07-27 at 08:57 +0800, Ian Kent wrote:
> > On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote:
> > > 
> > > On 07/26/2011 10:50 AM, Chuck Lever wrote:
> > > > 
> > > > On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote:
> > > > 
> > > >> From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
> > > >>
> > > >> The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and
> > > >> clnttcp6_create and the server functions svcudp6_bufcreate(),
> > > >> svctcp6_create() and svcudp6_create() are not included in the library
> > > >> whe libtirpc is built.
> > > > 
> > > > Are these part of the libtirpc standard API?  I'm not sure why we would need them if, say, Solaris does not support these.
> > > It appears they are not since they are not mentioned the man pages.....
> > > But, at least in the autofs code, they are expected
> > >    https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0
> > > 
> > > Ian, where else are these routines defined? 
> > 
> > Now that I look I can't find the original source tar that was used for
> > libtirpc, thought I had it.
> 
> Found what I had.
> 
> AFAICT what I think was the original source doesn't have any IPv6 code
> that I can see.
> 
> Worse, these functions were excluded with the "#ifdef INET6_NOT_USED"
> macro as far back as libtirpc version 0.1.5 so, my bad, sorry.
> 
> > 
> > The story is that long ago when I changed autofs to use libtirpc (to
> > make it ready for IPv6) I found these functions in the source and they
> > were (obviously) the IPv6 counterparts for the corresponding IPv4
> > functions which I was already using, so I used them. It took me quite a
> > while to realize my code wasn't working and then I found that somewhere
> > along the line they have been excluded, oops!
> > 
> > If there are to be no IPv6 counterparts for the corresponding IPv4
> > functions which functions should I use then?
> 
> So what can I use?
> 
> It seems to me that these functions would be useful for people porting
> code that uses the corresponding IPv4 functions so could we define them
> please. At some point someone must have had that same idea ....

Found one more thing that looks relevant, these functions were defined
in glibc in 2000-01-23 so they may be used by others as well.

> 
> > 
> > > 
> > > steved
> > > 
> > > > 
> > > >> Signed-off-by: Steve Dickson <steved-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > >> ---
> > > >> src/rpc_soc.c |    4 ++--
> > > >> 1 files changed, 2 insertions(+), 2 deletions(-)
> > > >>
> > > >> diff --git a/src/rpc_soc.c b/src/rpc_soc.c
> > > >> index c678429..584ac71 100644
> > > >> --- a/src/rpc_soc.c
> > > >> +++ b/src/rpc_soc.c
> > > >> @@ -236,7 +236,7 @@ clnttcp_create(raddr, prog, vers, sockp, sendsz, recvsz)
> > > >>
> > > >> /* IPv6 version of clnt*_*create */
> > > >>
> > > >> -#ifdef INET6_NOT_USED
> > > >> +#ifdef INET6
> > > >>
> > > >> CLIENT *
> > > >> clntudp6_bufcreate(raddr, prog, vers, wait, sockp, sendsz, recvsz)
> > > >> @@ -392,7 +392,7 @@ svcraw_create()
> > > >>
> > > >>
> > > >> /* IPV6 version */
> > > >> -#ifdef INET6_NOT_USED
> > > >> +#ifdef INET6
> > > >> SVCXPRT *
> > > >> svcudp6_bufcreate(fd, sendsz, recvsz)
> > > >> 	int fd;
> > > >> -- 
> > > >> 1.7.6
> > > >>
> > > >>
> > > >> ------------------------------------------------------------------------------
> > > >> Magic Quadrant for Content-Aware Data Loss Prevention
> > > >> Research study explores the data loss prevention market. Includes in-depth
> > > >> analysis on the changes within the DLP market, and the criteria used to
> > > >> evaluate the strengths and weaknesses of these DLP solutions.
> > > >> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> > > >> _______________________________________________
> > > >> Libtirpc-devel mailing list
> > > >> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > > >> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
> > > > 
> > > 
> > > ------------------------------------------------------------------------------
> > > Got Input?   Slashdot Needs You.
> > > Take our quick survey online.  Come on, we don't ask for help often.
> > > Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> > > http://p.sf.net/sfu/slashdot-survey
> > > _______________________________________________
> > > Libtirpc-devel mailing list
> > > Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > > https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
> > 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Chuck Lever]

On Jul 26, 2011, at 10:02 PM, Ian Kent wrote:

> On Wed, 2011-07-27 at 09:23 +0800, Ian Kent wrote:
>> On Wed, 2011-07-27 at 08:57 +0800, Ian Kent wrote:
>>> On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote:
>>>> 
>>>> On 07/26/2011 10:50 AM, Chuck Lever wrote:
>>>>> 
>>>>> On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote:
>>>>> 
>>>>>> From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
>>>>>> 
>>>>>> The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and
>>>>>> clnttcp6_create and the server functions svcudp6_bufcreate(),
>>>>>> svctcp6_create() and svcudp6_create() are not included in the library
>>>>>> whe libtirpc is built.
>>>>> 
>>>>> Are these part of the libtirpc standard API?  I'm not sure why we would need them if, say, Solaris does not support these.
>>>> It appears they are not since they are not mentioned the man pages.....
>>>> But, at least in the autofs code, they are expected
>>>>   https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0
>>>> 
>>>> Ian, where else are these routines defined? 
>>> 
>>> Now that I look I can't find the original source tar that was used for
>>> libtirpc, thought I had it.
>> 
>> Found what I had.
>> 
>> AFAICT what I think was the original source doesn't have any IPv6 code
>> that I can see.
>> 
>> Worse, these functions were excluded with the "#ifdef INET6_NOT_USED"
>> macro as far back as libtirpc version 0.1.5 so, my bad, sorry.
>> 
>>> 
>>> The story is that long ago when I changed autofs to use libtirpc (to
>>> make it ready for IPv6) I found these functions in the source and they
>>> were (obviously) the IPv6 counterparts for the corresponding IPv4
>>> functions which I was already using, so I used them. It took me quite a
>>> while to realize my code wasn't working and then I found that somewhere
>>> along the line they have been excluded, oops!
>>> 
>>> If there are to be no IPv6 counterparts for the corresponding IPv4
>>> functions which functions should I use then?
>> 
>> So what can I use?
>> 
>> It seems to me that these functions would be useful for people porting
>> code that uses the corresponding IPv4 functions so could we define them
>> please. At some point someone must have had that same idea ....
> 
> Found one more thing that looks relevant, these functions were defined
> in glibc in 2000-01-23 so they may be used by others as well.

I checked in glibc 2.7 (though not thoroughly) and did not find them.

> 
>> 
>>> 
>>>> 
>>>> steved
>>>> 
>>>>> 
>>>>>> Signed-off-by: Steve Dickson <steved-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>>>> ---
>>>>>> src/rpc_soc.c |    4 ++--
>>>>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>>>> 
>>>>>> diff --git a/src/rpc_soc.c b/src/rpc_soc.c
>>>>>> index c678429..584ac71 100644
>>>>>> --- a/src/rpc_soc.c
>>>>>> +++ b/src/rpc_soc.c
>>>>>> @@ -236,7 +236,7 @@ clnttcp_create(raddr, prog, vers, sockp, sendsz, recvsz)
>>>>>> 
>>>>>> /* IPv6 version of clnt*_*create */
>>>>>> 
>>>>>> -#ifdef INET6_NOT_USED
>>>>>> +#ifdef INET6
>>>>>> 
>>>>>> CLIENT *
>>>>>> clntudp6_bufcreate(raddr, prog, vers, wait, sockp, sendsz, recvsz)
>>>>>> @@ -392,7 +392,7 @@ svcraw_create()
>>>>>> 
>>>>>> 
>>>>>> /* IPV6 version */
>>>>>> -#ifdef INET6_NOT_USED
>>>>>> +#ifdef INET6
>>>>>> SVCXPRT *
>>>>>> svcudp6_bufcreate(fd, sendsz, recvsz)
>>>>>> 	int fd;
>>>>>> -- 
>>>>>> 1.7.6
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Magic Quadrant for Content-Aware Data Loss Prevention
>>>>>> Research study explores the data loss prevention market. Includes in-depth
>>>>>> analysis on the changes within the DLP market, and the criteria used to
>>>>>> evaluate the strengths and weaknesses of these DLP solutions.
>>>>>> http://www.accelacomm.com/jaw/sfnl/114/51385063/
>>>>>> _______________________________________________
>>>>>> Libtirpc-devel mailing list
>>>>>> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>>>>> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
>>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Got Input?   Slashdot Needs You.
>>>> Take our quick survey online.  Come on, we don't ask for help often.
>>>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
>>>> http://p.sf.net/sfu/slashdot-survey
>>>> _______________________________________________
>>>> Libtirpc-devel mailing list
>>>> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>>> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
>>> 
>> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Chuck Lever]

On Jul 26, 2011, at 9:23 PM, Ian Kent wrote:

> On Wed, 2011-07-27 at 08:57 +0800, Ian Kent wrote:
>> On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote:
>>> 
>>> On 07/26/2011 10:50 AM, Chuck Lever wrote:
>>>> 
>>>> On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote:
>>>> 
>>>>> From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
>>>>> 
>>>>> The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and
>>>>> clnttcp6_create and the server functions svcudp6_bufcreate(),
>>>>> svctcp6_create() and svcudp6_create() are not included in the library
>>>>> whe libtirpc is built.
>>>> 
>>>> Are these part of the libtirpc standard API?  I'm not sure why we would need them if, say, Solaris does not support these.
>>> It appears they are not since they are not mentioned the man pages.....
>>> But, at least in the autofs code, they are expected
>>>   https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0
>>> 
>>> Ian, where else are these routines defined? 
>> 
>> Now that I look I can't find the original source tar that was used for
>> libtirpc, thought I had it.
> 
> Found what I had.
> 
> AFAICT what I think was the original source doesn't have any IPv6 code
> that I can see.
> 
> Worse, these functions were excluded with the "#ifdef INET6_NOT_USED"
> macro as far back as libtirpc version 0.1.5 so, my bad, sorry.
> 
>> 
>> The story is that long ago when I changed autofs to use libtirpc (to
>> make it ready for IPv6) I found these functions in the source and they
>> were (obviously) the IPv6 counterparts for the corresponding IPv4
>> functions which I was already using, so I used them. It took me quite a
>> while to realize my code wasn't working and then I found that somewhere
>> along the line they have been excluded, oops!
>> 
>> If there are to be no IPv6 counterparts for the corresponding IPv4
>> functions which functions should I use then?
> 
> So what can I use?
> 
> It seems to me that these functions would be useful for people porting
> code that uses the corresponding IPv4 functions so could we define them
> please. At some point someone must have had that same idea ....

It looks to me like these functions were part of an original attempt at IPv6 support that was abandoned long ago.  They are not part of TI-RPC, but as you observed, they are merely IPv6 versions of the legacy RPC API. I don't see these implemented in glibc, for example.

For IPv6 support, use functions that are part of the modern libtirpc API.  This is described in Sun doc 816-1435.  You probably will be most successful with the "simplified interface" which is described in Chapter 4. You might need somewhat more extensive surgery since I'm guessing you have separate code paths to invoke the IPv4 and IPv6 legacy RPC functions; generally speaking that should not be needed when using the libtirpc API.



> 
>> 
>>> 
>>> steved
>>> 
>>>> 
>>>>> Signed-off-by: Steve Dickson <steved-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>>> ---
>>>>> src/rpc_soc.c |    4 ++--
>>>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>>> 
>>>>> diff --git a/src/rpc_soc.c b/src/rpc_soc.c
>>>>> index c678429..584ac71 100644
>>>>> --- a/src/rpc_soc.c
>>>>> +++ b/src/rpc_soc.c
>>>>> @@ -236,7 +236,7 @@ clnttcp_create(raddr, prog, vers, sockp, sendsz, recvsz)
>>>>> 
>>>>> /* IPv6 version of clnt*_*create */
>>>>> 
>>>>> -#ifdef INET6_NOT_USED
>>>>> +#ifdef INET6
>>>>> 
>>>>> CLIENT *
>>>>> clntudp6_bufcreate(raddr, prog, vers, wait, sockp, sendsz, recvsz)
>>>>> @@ -392,7 +392,7 @@ svcraw_create()
>>>>> 
>>>>> 
>>>>> /* IPV6 version */
>>>>> -#ifdef INET6_NOT_USED
>>>>> +#ifdef INET6
>>>>> SVCXPRT *
>>>>> svcudp6_bufcreate(fd, sendsz, recvsz)
>>>>> 	int fd;
>>>>> -- 
>>>>> 1.7.6
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Magic Quadrant for Content-Aware Data Loss Prevention
>>>>> Research study explores the data loss prevention market. Includes in-depth
>>>>> analysis on the changes within the DLP market, and the criteria used to
>>>>> evaluate the strengths and weaknesses of these DLP solutions.
>>>>> http://www.accelacomm.com/jaw/sfnl/114/51385063/
>>>>> _______________________________________________
>>>>> Libtirpc-devel mailing list
>>>>> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>>>> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
>>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Got Input?   Slashdot Needs You.
>>> Take our quick survey online.  Come on, we don't ask for help often.
>>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
>>> http://p.sf.net/sfu/slashdot-survey
>>> _______________________________________________
>>> Libtirpc-devel mailing list
>>> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
>> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Ian Kent]

On Tue, 2011-07-26 at 22:09 -0400, Chuck Lever wrote:
> On Jul 26, 2011, at 9:23 PM, Ian Kent wrote:
> 
> > On Wed, 2011-07-27 at 08:57 +0800, Ian Kent wrote:
> >> On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote:
> >>> 
> >>> On 07/26/2011 10:50 AM, Chuck Lever wrote:
> >>>> 
> >>>> On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote:
> >>>> 
> >>>>> From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
> >>>>> 
> >>>>> The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and
> >>>>> clnttcp6_create and the server functions svcudp6_bufcreate(),
> >>>>> svctcp6_create() and svcudp6_create() are not included in the library
> >>>>> whe libtirpc is built.
> >>>> 
> >>>> Are these part of the libtirpc standard API?  I'm not sure why we would need them if, say, Solaris does not support these.
> >>> It appears they are not since they are not mentioned the man pages.....
> >>> But, at least in the autofs code, they are expected
> >>>   https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0
> >>> 
> >>> Ian, where else are these routines defined? 
> >> 
> >> Now that I look I can't find the original source tar that was used for
> >> libtirpc, thought I had it.
> > 
> > Found what I had.
> > 
> > AFAICT what I think was the original source doesn't have any IPv6 code
> > that I can see.
> > 
> > Worse, these functions were excluded with the "#ifdef INET6_NOT_USED"
> > macro as far back as libtirpc version 0.1.5 so, my bad, sorry.
> > 
> >> 
> >> The story is that long ago when I changed autofs to use libtirpc (to
> >> make it ready for IPv6) I found these functions in the source and they
> >> were (obviously) the IPv6 counterparts for the corresponding IPv4
> >> functions which I was already using, so I used them. It took me quite a
> >> while to realize my code wasn't working and then I found that somewhere
> >> along the line they have been excluded, oops!
> >> 
> >> If there are to be no IPv6 counterparts for the corresponding IPv4
> >> functions which functions should I use then?
> > 
> > So what can I use?
> > 
> > It seems to me that these functions would be useful for people porting
> > code that uses the corresponding IPv4 functions so could we define them
> > please. At some point someone must have had that same idea ....
> 
> It looks to me like these functions were part of an original attempt
> at IPv6 support that was abandoned long ago.  They are not part of
> TI-RPC, but as you observed, they are merely IPv6 versions of the
> legacy RPC API. I don't see these implemented in glibc, for example.
> 
> For IPv6 support, use functions that are part of the modern libtirpc
> API.  This is described in Sun doc 816-1435.  You probably will be
> most successful with the "simplified interface" which is described in
> Chapter 4. You might need somewhat more extensive surgery since I'm
> guessing you have separate code paths to invoke the IPv4 and IPv6
> legacy RPC functions; generally speaking that should not be needed
> when using the libtirpc API.

I doubt the simplified interface will be adequate since this code was
written because of a need for greater control over timeouts. Perhaps
that won't be the case, I don't know yet.

Your suggestion amounts to saying I need to re-write all my RPC code.

> 
> 
> 
> > 
> >> 
> >>> 
> >>> steved
> >>> 
> >>>> 
> >>>>> Signed-off-by: Steve Dickson <steved-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>>>> ---
> >>>>> src/rpc_soc.c |    4 ++--
> >>>>> 1 files changed, 2 insertions(+), 2 deletions(-)
> >>>>> 
> >>>>> diff --git a/src/rpc_soc.c b/src/rpc_soc.c
> >>>>> index c678429..584ac71 100644
> >>>>> --- a/src/rpc_soc.c
> >>>>> +++ b/src/rpc_soc.c
> >>>>> @@ -236,7 +236,7 @@ clnttcp_create(raddr, prog, vers, sockp, sendsz, recvsz)
> >>>>> 
> >>>>> /* IPv6 version of clnt*_*create */
> >>>>> 
> >>>>> -#ifdef INET6_NOT_USED
> >>>>> +#ifdef INET6
> >>>>> 
> >>>>> CLIENT *
> >>>>> clntudp6_bufcreate(raddr, prog, vers, wait, sockp, sendsz, recvsz)
> >>>>> @@ -392,7 +392,7 @@ svcraw_create()
> >>>>> 
> >>>>> 
> >>>>> /* IPV6 version */
> >>>>> -#ifdef INET6_NOT_USED
> >>>>> +#ifdef INET6
> >>>>> SVCXPRT *
> >>>>> svcudp6_bufcreate(fd, sendsz, recvsz)
> >>>>> 	int fd;
> >>>>> -- 
> >>>>> 1.7.6
> >>>>> 
> >>>>> 
> >>>>> ------------------------------------------------------------------------------
> >>>>> Magic Quadrant for Content-Aware Data Loss Prevention
> >>>>> Research study explores the data loss prevention market. Includes in-depth
> >>>>> analysis on the changes within the DLP market, and the criteria used to
> >>>>> evaluate the strengths and weaknesses of these DLP solutions.
> >>>>> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> >>>>> _______________________________________________
> >>>>> Libtirpc-devel mailing list
> >>>>> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> >>>>> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
> >>>> 
> >>> 
> >>> ------------------------------------------------------------------------------
> >>> Got Input?   Slashdot Needs You.
> >>> Take our quick survey online.  Come on, we don't ask for help often.
> >>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> >>> http://p.sf.net/sfu/slashdot-survey
> >>> _______________________________________________
> >>> Libtirpc-devel mailing list
> >>> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> >>> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
> >> 
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Ian Kent]

On Wed, 2011-07-27 at 10:40 +0800, Ian Kent wrote:
> On Tue, 2011-07-26 at 22:09 -0400, Chuck Lever wrote:
> > On Jul 26, 2011, at 9:23 PM, Ian Kent wrote:
> > 
> > > On Wed, 2011-07-27 at 08:57 +0800, Ian Kent wrote:
> > >> On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote:
> > >>> 
> > >>> On 07/26/2011 10:50 AM, Chuck Lever wrote:
> > >>>> 
> > >>>> On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote:
> > >>>> 
> > >>>>> From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
> > >>>>> 
> > >>>>> The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and
> > >>>>> clnttcp6_create and the server functions svcudp6_bufcreate(),
> > >>>>> svctcp6_create() and svcudp6_create() are not included in the library
> > >>>>> whe libtirpc is built.
> > >>>> 
> > >>>> Are these part of the libtirpc standard API?  I'm not sure why we would need them if, say, Solaris does not support these.
> > >>> It appears they are not since they are not mentioned the man pages.....
> > >>> But, at least in the autofs code, they are expected
> > >>>   https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0
> > >>> 
> > >>> Ian, where else are these routines defined? 
> > >> 
> > >> Now that I look I can't find the original source tar that was used for
> > >> libtirpc, thought I had it.
> > > 
> > > Found what I had.
> > > 
> > > AFAICT what I think was the original source doesn't have any IPv6 code
> > > that I can see.
> > > 
> > > Worse, these functions were excluded with the "#ifdef INET6_NOT_USED"
> > > macro as far back as libtirpc version 0.1.5 so, my bad, sorry.
> > > 
> > >> 
> > >> The story is that long ago when I changed autofs to use libtirpc (to
> > >> make it ready for IPv6) I found these functions in the source and they
> > >> were (obviously) the IPv6 counterparts for the corresponding IPv4
> > >> functions which I was already using, so I used them. It took me quite a
> > >> while to realize my code wasn't working and then I found that somewhere
> > >> along the line they have been excluded, oops!
> > >> 
> > >> If there are to be no IPv6 counterparts for the corresponding IPv4
> > >> functions which functions should I use then?
> > > 
> > > So what can I use?
> > > 
> > > It seems to me that these functions would be useful for people porting
> > > code that uses the corresponding IPv4 functions so could we define them
> > > please. At some point someone must have had that same idea ....
> > 
> > It looks to me like these functions were part of an original attempt
> > at IPv6 support that was abandoned long ago.  They are not part of
> > TI-RPC, but as you observed, they are merely IPv6 versions of the
> > legacy RPC API. I don't see these implemented in glibc, for example.
> > 
> > For IPv6 support, use functions that are part of the modern libtirpc
> > API.  This is described in Sun doc 816-1435.  You probably will be
> > most successful with the "simplified interface" which is described in
> > Chapter 4. You might need somewhat more extensive surgery since I'm
> > guessing you have separate code paths to invoke the IPv4 and IPv6
> > legacy RPC functions; generally speaking that should not be needed
> > when using the libtirpc API.
> 
> I doubt the simplified interface will be adequate since this code was
> written because of a need for greater control over timeouts. Perhaps
> that won't be the case, I don't know yet.
> 
> Your suggestion amounts to saying I need to re-write all my RPC code.

That comment is a bit dramatic, sorry.

Actually I should be able to replace these calls with the contents of
the functions as they are in libtirpc without too much trouble.

> 
> > 
> > 
> > 
> > > 
> > >> 
> > >>> 
> > >>> steved
> > >>> 
> > >>>> 
> > >>>>> Signed-off-by: Steve Dickson <steved-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > >>>>> ---
> > >>>>> src/rpc_soc.c |    4 ++--
> > >>>>> 1 files changed, 2 insertions(+), 2 deletions(-)
> > >>>>> 
> > >>>>> diff --git a/src/rpc_soc.c b/src/rpc_soc.c
> > >>>>> index c678429..584ac71 100644
> > >>>>> --- a/src/rpc_soc.c
> > >>>>> +++ b/src/rpc_soc.c
> > >>>>> @@ -236,7 +236,7 @@ clnttcp_create(raddr, prog, vers, sockp, sendsz, recvsz)
> > >>>>> 
> > >>>>> /* IPv6 version of clnt*_*create */
> > >>>>> 
> > >>>>> -#ifdef INET6_NOT_USED
> > >>>>> +#ifdef INET6
> > >>>>> 
> > >>>>> CLIENT *
> > >>>>> clntudp6_bufcreate(raddr, prog, vers, wait, sockp, sendsz, recvsz)
> > >>>>> @@ -392,7 +392,7 @@ svcraw_create()
> > >>>>> 
> > >>>>> 
> > >>>>> /* IPV6 version */
> > >>>>> -#ifdef INET6_NOT_USED
> > >>>>> +#ifdef INET6
> > >>>>> SVCXPRT *
> > >>>>> svcudp6_bufcreate(fd, sendsz, recvsz)
> > >>>>> 	int fd;
> > >>>>> -- 
> > >>>>> 1.7.6
> > >>>>> 
> > >>>>> 
> > >>>>> ------------------------------------------------------------------------------
> > >>>>> Magic Quadrant for Content-Aware Data Loss Prevention
> > >>>>> Research study explores the data loss prevention market. Includes in-depth
> > >>>>> analysis on the changes within the DLP market, and the criteria used to
> > >>>>> evaluate the strengths and weaknesses of these DLP solutions.
> > >>>>> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> > >>>>> _______________________________________________
> > >>>>> Libtirpc-devel mailing list
> > >>>>> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > >>>>> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
> > >>>> 
> > >>> 
> > >>> ------------------------------------------------------------------------------
> > >>> Got Input?   Slashdot Needs You.
> > >>> Take our quick survey online.  Come on, we don't ask for help often.
> > >>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> > >>> http://p.sf.net/sfu/slashdot-survey
> > >>> _______________________________________________
> > >>> Libtirpc-devel mailing list
> > >>> Libtirpc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > >>> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
> > >> 
> > > 
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Chuck Lever]

On Jul 26, 2011, at 10:40 PM, Ian Kent wrote:

> On Tue, 2011-07-26 at 22:09 -0400, Chuck Lever wrote:
>> On Jul 26, 2011, at 9:23 PM, Ian Kent wrote:
>> 
>>> On Wed, 2011-07-27 at 08:57 +0800, Ian Kent wrote:
>>>> On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote:
>>>>> 
>>>>> On 07/26/2011 10:50 AM, Chuck Lever wrote:
>>>>>> 
>>>>>> On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote:
>>>>>> 
>>>>>>> From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
>>>>>>> 
>>>>>>> The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and
>>>>>>> clnttcp6_create and the server functions svcudp6_bufcreate(),
>>>>>>> svctcp6_create() and svcudp6_create() are not included in the library
>>>>>>> whe libtirpc is built.
>>>>>> 
>>>>>> Are these part of the libtirpc standard API?  I'm not sure why we would need them if, say, Solaris does not support these.
>>>>> It appears they are not since they are not mentioned the man pages.....
>>>>> But, at least in the autofs code, they are expected
>>>>>  https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0
>>>>> 
>>>>> Ian, where else are these routines defined? 
>>>> 
>>>> Now that I look I can't find the original source tar that was used for
>>>> libtirpc, thought I had it.
>>> 
>>> Found what I had.
>>> 
>>> AFAICT what I think was the original source doesn't have any IPv6 code
>>> that I can see.
>>> 
>>> Worse, these functions were excluded with the "#ifdef INET6_NOT_USED"
>>> macro as far back as libtirpc version 0.1.5 so, my bad, sorry.
>>> 
>>>> 
>>>> The story is that long ago when I changed autofs to use libtirpc (to
>>>> make it ready for IPv6) I found these functions in the source and they
>>>> were (obviously) the IPv6 counterparts for the corresponding IPv4
>>>> functions which I was already using, so I used them. It took me quite a
>>>> while to realize my code wasn't working and then I found that somewhere
>>>> along the line they have been excluded, oops!
>>>> 
>>>> If there are to be no IPv6 counterparts for the corresponding IPv4
>>>> functions which functions should I use then?
>>> 
>>> So what can I use?
>>> 
>>> It seems to me that these functions would be useful for people porting
>>> code that uses the corresponding IPv4 functions so could we define them
>>> please. At some point someone must have had that same idea ....
>> 
>> It looks to me like these functions were part of an original attempt
>> at IPv6 support that was abandoned long ago.  They are not part of
>> TI-RPC, but as you observed, they are merely IPv6 versions of the
>> legacy RPC API. I don't see these implemented in glibc, for example.
>> 
>> For IPv6 support, use functions that are part of the modern libtirpc
>> API.  This is described in Sun doc 816-1435.  You probably will be
>> most successful with the "simplified interface" which is described in
>> Chapter 4. You might need somewhat more extensive surgery since I'm
>> guessing you have separate code paths to invoke the IPv4 and IPv6
>> legacy RPC functions; generally speaking that should not be needed
>> when using the libtirpc API.
> 
> I doubt the simplified interface will be adequate since this code was
> written because of a need for greater control over timeouts. Perhaps
> that won't be the case, I don't know yet.

If you want control over connection timeouts, use the expert-level or bottom-level interfaces.  Otherwise you can set per-RPC timeouts when clnt_call(3t) is invoked.  nfs-utils has some example code (support/nfs/rpc_socket.c is one place to look).

> Your suggestion amounts to saying I need to re-write all my RPC code.

The substantial change with client-side TI-RPC is how CLIENTs are created.  The other RPC operations are similar or the same as they were with the legacy API.  Once you get over getnetconfigent(3t) it's really not as bad as it looks.

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Ian Kent]

On Tue, 2011-07-26 at 23:30 -0400, Chuck Lever wrote:
> On Jul 26, 2011, at 10:40 PM, Ian Kent wrote:
> 
> > On Tue, 2011-07-26 at 22:09 -0400, Chuck Lever wrote:
> >> On Jul 26, 2011, at 9:23 PM, Ian Kent wrote:
> >> 
> >>> On Wed, 2011-07-27 at 08:57 +0800, Ian Kent wrote:
> >>>> On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote:
> >>>>> 
> >>>>> On 07/26/2011 10:50 AM, Chuck Lever wrote:
> >>>>>> 
> >>>>>> On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote:
> >>>>>> 
> >>>>>>> From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
> >>>>>>> 
> >>>>>>> The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and
> >>>>>>> clnttcp6_create and the server functions svcudp6_bufcreate(),
> >>>>>>> svctcp6_create() and svcudp6_create() are not included in the library
> >>>>>>> whe libtirpc is built.
> >>>>>> 
> >>>>>> Are these part of the libtirpc standard API?  I'm not sure why we would need them if, say, Solaris does not support these.
> >>>>> It appears they are not since they are not mentioned the man pages.....
> >>>>> But, at least in the autofs code, they are expected
> >>>>>  https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0
> >>>>> 
> >>>>> Ian, where else are these routines defined? 
> >>>> 
> >>>> Now that I look I can't find the original source tar that was used for
> >>>> libtirpc, thought I had it.
> >>> 
> >>> Found what I had.
> >>> 
> >>> AFAICT what I think was the original source doesn't have any IPv6 code
> >>> that I can see.
> >>> 
> >>> Worse, these functions were excluded with the "#ifdef INET6_NOT_USED"
> >>> macro as far back as libtirpc version 0.1.5 so, my bad, sorry.
> >>> 
> >>>> 
> >>>> The story is that long ago when I changed autofs to use libtirpc (to
> >>>> make it ready for IPv6) I found these functions in the source and they
> >>>> were (obviously) the IPv6 counterparts for the corresponding IPv4
> >>>> functions which I was already using, so I used them. It took me quite a
> >>>> while to realize my code wasn't working and then I found that somewhere
> >>>> along the line they have been excluded, oops!
> >>>> 
> >>>> If there are to be no IPv6 counterparts for the corresponding IPv4
> >>>> functions which functions should I use then?
> >>> 
> >>> So what can I use?
> >>> 
> >>> It seems to me that these functions would be useful for people porting
> >>> code that uses the corresponding IPv4 functions so could we define them
> >>> please. At some point someone must have had that same idea ....
> >> 
> >> It looks to me like these functions were part of an original attempt
> >> at IPv6 support that was abandoned long ago.  They are not part of
> >> TI-RPC, but as you observed, they are merely IPv6 versions of the
> >> legacy RPC API. I don't see these implemented in glibc, for example.
> >> 
> >> For IPv6 support, use functions that are part of the modern libtirpc
> >> API.  This is described in Sun doc 816-1435.  You probably will be
> >> most successful with the "simplified interface" which is described in
> >> Chapter 4. You might need somewhat more extensive surgery since I'm
> >> guessing you have separate code paths to invoke the IPv4 and IPv6
> >> legacy RPC functions; generally speaking that should not be needed
> >> when using the libtirpc API.
> > 
> > I doubt the simplified interface will be adequate since this code was
> > written because of a need for greater control over timeouts. Perhaps
> > that won't be the case, I don't know yet.
> 
> If you want control over connection timeouts, use the expert-level or
> bottom-level interfaces.  Otherwise you can set per-RPC timeouts when
> clnt_call(3t) is invoked.  nfs-utils has some example code
> (support/nfs/rpc_socket.c is one place to look).
> 
> > Your suggestion amounts to saying I need to re-write all my RPC
> code.
> 
> The substantial change with client-side TI-RPC is how CLIENTs are
> created.  The other RPC operations are similar or the same as they
> were with the legacy API.  Once you get over getnetconfigent(3t) it's
> really not as bad as it looks.
> 

Sure, but it's the dependent code in autofs that uses the RPC routines
that will force me to keep the interface. But, like I said, it may be a
non-issue since I can lift these routines straight out of libtirpc (as
long as I attribute copyright according to the comment in the source
file).

Ian

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Ian Kent]

On Wed, 2011-07-27 at 11:39 +0800, Ian Kent wrote:
> On Tue, 2011-07-26 at 23:30 -0400, Chuck Lever wrote:
> > On Jul 26, 2011, at 10:40 PM, Ian Kent wrote:
> > 
> > > On Tue, 2011-07-26 at 22:09 -0400, Chuck Lever wrote:
> > >> On Jul 26, 2011, at 9:23 PM, Ian Kent wrote:
> > >> 
> > >>> On Wed, 2011-07-27 at 08:57 +0800, Ian Kent wrote:
> > >>>> On Tue, 2011-07-26 at 17:13 -0400, Steve Dickson wrote:
> > >>>>> 
> > >>>>> On 07/26/2011 10:50 AM, Chuck Lever wrote:
> > >>>>>> 
> > >>>>>> On Jul 26, 2011, at 2:29 PM, Steve Dickson wrote:
> > >>>>>> 
> > >>>>>>> From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
> > >>>>>>> 
> > >>>>>>> The IPv6 client functions clntudp6_bufcreate(), clntudp6_create and
> > >>>>>>> clnttcp6_create and the server functions svcudp6_bufcreate(),
> > >>>>>>> svctcp6_create() and svcudp6_create() are not included in the library
> > >>>>>>> whe libtirpc is built.
> > >>>>>> 
> > >>>>>> Are these part of the libtirpc standard API?  I'm not sure why we would need them if, say, Solaris does not support these.
> > >>>>> It appears they are not since they are not mentioned the man pages.....
> > >>>>> But, at least in the autofs code, they are expected
> > >>>>>  https://bugzilla.redhat.com/show_bug.cgi?id=711956#c0
> > >>>>> 
> > >>>>> Ian, where else are these routines defined? 
> > >>>> 
> > >>>> Now that I look I can't find the original source tar that was used for
> > >>>> libtirpc, thought I had it.
> > >>> 
> > >>> Found what I had.
> > >>> 
> > >>> AFAICT what I think was the original source doesn't have any IPv6 code
> > >>> that I can see.
> > >>> 
> > >>> Worse, these functions were excluded with the "#ifdef INET6_NOT_USED"
> > >>> macro as far back as libtirpc version 0.1.5 so, my bad, sorry.
> > >>> 
> > >>>> 
> > >>>> The story is that long ago when I changed autofs to use libtirpc (to
> > >>>> make it ready for IPv6) I found these functions in the source and they
> > >>>> were (obviously) the IPv6 counterparts for the corresponding IPv4
> > >>>> functions which I was already using, so I used them. It took me quite a
> > >>>> while to realize my code wasn't working and then I found that somewhere
> > >>>> along the line they have been excluded, oops!
> > >>>> 
> > >>>> If there are to be no IPv6 counterparts for the corresponding IPv4
> > >>>> functions which functions should I use then?
> > >>> 
> > >>> So what can I use?
> > >>> 
> > >>> It seems to me that these functions would be useful for people porting
> > >>> code that uses the corresponding IPv4 functions so could we define them
> > >>> please. At some point someone must have had that same idea ....
> > >> 
> > >> It looks to me like these functions were part of an original attempt
> > >> at IPv6 support that was abandoned long ago.  They are not part of
> > >> TI-RPC, but as you observed, they are merely IPv6 versions of the
> > >> legacy RPC API. I don't see these implemented in glibc, for example.
> > >> 
> > >> For IPv6 support, use functions that are part of the modern libtirpc
> > >> API.  This is described in Sun doc 816-1435.  You probably will be
> > >> most successful with the "simplified interface" which is described in
> > >> Chapter 4. You might need somewhat more extensive surgery since I'm
> > >> guessing you have separate code paths to invoke the IPv4 and IPv6
> > >> legacy RPC functions; generally speaking that should not be needed
> > >> when using the libtirpc API.
> > > 
> > > I doubt the simplified interface will be adequate since this code was
> > > written because of a need for greater control over timeouts. Perhaps
> > > that won't be the case, I don't know yet.
> > 
> > If you want control over connection timeouts, use the expert-level or
> > bottom-level interfaces.  Otherwise you can set per-RPC timeouts when
> > clnt_call(3t) is invoked.  nfs-utils has some example code
> > (support/nfs/rpc_socket.c is one place to look).
> > 
> > > Your suggestion amounts to saying I need to re-write all my RPC
> > code.
> > 
> > The substantial change with client-side TI-RPC is how CLIENTs are
> > created.  The other RPC operations are similar or the same as they
> > were with the legacy API.  Once you get over getnetconfigent(3t) it's
> > really not as bad as it looks.
> > 
> 
> Sure, but it's the dependent code in autofs that uses the RPC routines
> that will force me to keep the interface. But, like I said, it may be a
> non-issue since I can lift these routines straight out of libtirpc (as
> long as I attribute copyright according to the comment in the source
> file).

That's not going to be straight forward either.

> 
> Ian


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Ian Kent]

On Tue, 2011-07-26 at 23:30 -0400, Chuck Lever wrote:
> >> 
> >> For IPv6 support, use functions that are part of the modern libtirpc
> >> API.  This is described in Sun doc 816-1435.  You probably will be
> >> most successful with the "simplified interface" which is described in
> >> Chapter 4. You might need somewhat more extensive surgery since I'm
> >> guessing you have separate code paths to invoke the IPv4 and IPv6
> >> legacy RPC functions; generally speaking that should not be needed
> >> when using the libtirpc API.
> > 
> > I doubt the simplified interface will be adequate since this code was
> > written because of a need for greater control over timeouts. Perhaps
> > that won't be the case, I don't know yet.
> 
> If you want control over connection timeouts, use the expert-level or
> bottom-level interfaces.  Otherwise you can set per-RPC timeouts when
> clnt_call(3t) is invoked.  nfs-utils has some example code
> (support/nfs/rpc_socket.c is one place to look).
> 
> > Your suggestion amounts to saying I need to re-write all my RPC
> code.
> 
> The substantial change with client-side TI-RPC is how CLIENTs are
> created.  The other RPC operations are similar or the same as they
> were with the legacy API.  Once you get over getnetconfigent(3t) it's
> really not as bad as it looks.
> 

Umm ...

Why is __rpcb_findaddr() declared in the public header files but not
defined anywhere is the source?

Why is __rpcb_findaddr_timed() defined in the source but not defined in
the public header files?


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Chuck Lever]

On Jul 27, 2011, at 10:26 PM, Ian Kent wrote:

> On Tue, 2011-07-26 at 23:30 -0400, Chuck Lever wrote:
>>>> 
>>>> For IPv6 support, use functions that are part of the modern libtirpc
>>>> API.  This is described in Sun doc 816-1435.  You probably will be
>>>> most successful with the "simplified interface" which is described in
>>>> Chapter 4. You might need somewhat more extensive surgery since I'm
>>>> guessing you have separate code paths to invoke the IPv4 and IPv6
>>>> legacy RPC functions; generally speaking that should not be needed
>>>> when using the libtirpc API.
>>> 
>>> I doubt the simplified interface will be adequate since this code was
>>> written because of a need for greater control over timeouts. Perhaps
>>> that won't be the case, I don't know yet.
>> 
>> If you want control over connection timeouts, use the expert-level or
>> bottom-level interfaces.  Otherwise you can set per-RPC timeouts when
>> clnt_call(3t) is invoked.  nfs-utils has some example code
>> (support/nfs/rpc_socket.c is one place to look).
>> 
>>> Your suggestion amounts to saying I need to re-write all my RPC
>> code.
>> 
>> The substantial change with client-side TI-RPC is how CLIENTs are
>> created.  The other RPC operations are similar or the same as they
>> were with the legacy API.  Once you get over getnetconfigent(3t) it's
>> really not as bad as it looks.
>> 
> 
> Umm ...
> 
> Why is __rpcb_findaddr() declared in the public header files but not
> defined anywhere is the source?
> 
> Why is __rpcb_findaddr_timed() defined in the source but not defined in
> the public header files?

This version of libtirpc was split from the Sun version over a decade ago when the code was immature.  So you're going to find this kind of thing in many places.

The TI-RPC API is defined in 816-1435.  You really shouldn't consider using any of the interfaces defined in the headers but not in that doc, as those are internal interfaces and can change.

On the other hand, we have at least two important RPC-based applications that can make use of this interface.  I wonder if it makes sense to harden that API but leave it hidden, so apps external to the library can depend on it.

Such apps would not be portable away from Linux nor to Linux distributions that don't have libtirpc yet.--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Ian Kent]

On Thu, 2011-07-28 at 07:20 -0400, Chuck Lever wrote:
> On Jul 27, 2011, at 10:26 PM, Ian Kent wrote:
> 
> > On Tue, 2011-07-26 at 23:30 -0400, Chuck Lever wrote:
> >>>> 
> >>>> For IPv6 support, use functions that are part of the modern libtirpc
> >>>> API.  This is described in Sun doc 816-1435.  You probably will be
> >>>> most successful with the "simplified interface" which is described in
> >>>> Chapter 4. You might need somewhat more extensive surgery since I'm
> >>>> guessing you have separate code paths to invoke the IPv4 and IPv6
> >>>> legacy RPC functions; generally speaking that should not be needed
> >>>> when using the libtirpc API.
> >>> 
> >>> I doubt the simplified interface will be adequate since this code was
> >>> written because of a need for greater control over timeouts. Perhaps
> >>> that won't be the case, I don't know yet.
> >> 
> >> If you want control over connection timeouts, use the expert-level or
> >> bottom-level interfaces.  Otherwise you can set per-RPC timeouts when
> >> clnt_call(3t) is invoked.  nfs-utils has some example code
> >> (support/nfs/rpc_socket.c is one place to look).
> >> 
> >>> Your suggestion amounts to saying I need to re-write all my RPC
> >> code.
> >> 
> >> The substantial change with client-side TI-RPC is how CLIENTs are
> >> created.  The other RPC operations are similar or the same as they
> >> were with the legacy API.  Once you get over getnetconfigent(3t) it's
> >> really not as bad as it looks.
> >> 
> > 
> > Umm ...
> > 
> > Why is __rpcb_findaddr() declared in the public header files but not
> > defined anywhere is the source?
> > 
> > Why is __rpcb_findaddr_timed() defined in the source but not defined in
> > the public header files?
> 
> This version of libtirpc was split from the Sun version over a decade
> ago when the code was immature.  So you're going to find this kind of
> thing in many places.

Yes, I was aware of that, but haven't paid enough attention to the doc.

> 
> The TI-RPC API is defined in 816-1435.  You really shouldn't consider
> using any of the interfaces defined in the headers but not in that
> doc, as those are internal interfaces and can change.

Ummm .. rpcb_getaddr() might be what I'm looking for, I'll look further.

> 
> On the other hand, we have at least two important RPC-based
> applications that can make use of this interface.  I wonder if it
> makes sense to harden that API but leave it hidden, so apps external
> to the library can depend on it.

Yeah, but if I can achieve what I need without it that's the way I'll
go. It looks like I might not be able to do what I want the way I want
with ti-rpc but it is still too early to tell. It's also too early to
tell if ti-rpc actually already does some or all of what I need already.
Time will tell.

One example of something I need is to control the timeout, not the
timeout for interactions after the client is constructed but the timeout
of the client construction itself, including any queries to rpcbind that
may be needed (hence why I want to do that manually too).

> 
> Such apps would not be portable away from Linux nor to Linux
> distributions that don't have libtirpc yet.

It sounds good but, as we all know, adding things that may need to
change or are not designed for external use can be a support burden.

Ian


--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Libtirpc-devel] [PATCH] Autofs configure fails to detect IPv6 when libtirpc is enabled

[Chuck Lever]

On Thu, Jul 28, 2011 at 10:33 AM, Ian Kent <ikent-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, 2011-07-28 at 07:20 -0400, Chuck Lever wrote:
>> On Jul 27, 2011, at 10:26 PM, Ian Kent wrote:
>> >
>> > Umm ...
>> >
>> > Why is __rpcb_findaddr() declared in the public header files but not
>> > defined anywhere is the source?
>> >
>> > Why is __rpcb_findaddr_timed() defined in the source but not defined in
>> > the public header files?
>>
>> This version of libtirpc was split from the Sun version over a decade
>> ago when the code was immature.  So you're going to find this kind of
>> thing in many places.
>
> Yes, I was aware of that, but haven't paid enough attention to the doc.
>
>>
>> The TI-RPC API is defined in 816-1435.  You really shouldn't consider
>> using any of the interfaces defined in the headers but not in that
>> doc, as those are internal interfaces and can change.
>
> Ummm .. rpcb_getaddr() might be what I'm looking for, I'll look further.
>
>>
>> On the other hand, we have at least two important RPC-based
>> applications that can make use of this interface.  I wonder if it
>> makes sense to harden that API but leave it hidden, so apps external
>> to the library can depend on it.
>
> Yeah, but if I can achieve what I need without it that's the way I'll
> go. It looks like I might not be able to do what I want the way I want
> with ti-rpc but it is still too early to tell. It's also too early to
> tell if ti-rpc actually already does some or all of what I need already.
> Time will tell.
>
> One example of something I need is to control the timeout, not the
> timeout for interactions after the client is constructed but the timeout
> of the client construction itself, including any queries to rpcbind that
> may be needed (hence why I want to do that manually too).

Yes, nfs-utils does this too.  See support/nfs/rpc_socket.c.  It looks
a lot like what is done in autofs's lib/rpc_subs.c.

-- 
"Blast this Christmas music!  It's joyful _and_ triumphant!"
 -- The Grinch
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html