svn commit: branches/uClibc-nptl/libc/inet

Khem Raj raj.khem at gmail.com
Tue Nov 25 22:55:37 UTC 2008


On Sun, Nov 23, 2008 at 4:48 AM, Denys Vlasenko
<vda.linux at googlemail.com> wrote:
> On Sunday 23 November 2008 10:02, Khem Raj wrote:
>> > I do not propose it to be removed.
>> > I want it to be explained in the comment
>> > in the Makefile.
>>
>> It has been explained when it was added. I did not want to repeat the
>> same comment again. (see r13095)
>
> http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/inet/Makefile.in?rev=12101&r1=12091&r2=12101&diff_format=h
>
> I don't see it there.

Sure because you are barking up the wrong tree :) I mentioned r13095 try
 svn log -r13095

>
>> > I looked at it and it _looks_ like it is not needed.
>> > Actually, I still don't see why it is needed,
>>
>> Like errno Its made a TLS variable as a result every thread will have
>> its own _res and hence the functions altering _res will be thread safe
>> and have more deterministic behaviour in multithreaded env.
>
> Therefore you need to add  _res_state.c? I simply don't
> see a connection.
>
> Two comments: busybox.net has a problem with filesystem being
> in RO state for some time a few days ago, and maybe that's
> the reason why I don't see rev. 24107 there. Last one is 24069:
>
> http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/inet/Makefile.in?view=log
>
> You might want to commit the change again.

Well generally its a good thing to check SCM logs for changes thats
one of many reasons why we have them.

>
> Second comment about the change itself:
>
>> --- branches/uClibc-nptl/libc/inet/Makefile.in        2008-11-20 23:41:56 UTC (rev 24106)
>> +++ branches/uClibc-nptl/libc/inet/Makefile.in        2008-11-21 05:22:12 UTC (rev 24107)
>> @@ -42,7 +42,7 @@
>>       gethostbyaddr_r.c gethostbyname_r.c gethostbyname2_r.c gethostent_r.c \
>>       gethostbyaddr.c gethostbyname.c gethostbyname2.c gethostent.c \
>>       res_init.c res_query.c res_comp.c ns_name.c \
>> -     ethers.c
>> +     ethers.c _res_state.c
>
> Please, point me to the part of the source tree (not svn log etc,
> the tree itself) which will clear the confusion of
> the hypothetical guy who reads the above and asks himself
> "WTF is _res_state.c and why is it here?".
> There is neither "*_res_state*" file anywhere in the tree,
> nor "_res_state." string anywhere in the tree.

Are you looking at the correct tree ? its on uclibc-nptl branch its
not on trunk.

I _really_ do not understand what you want to know. If you are worried
about how they are organised, go ahead propose something better
we will be happy to include it. Functionality wisw it is doing what it
is indended for. Furthermore if you are interested to know more
I would suggest to poke into nptl implementation and get more insights.

-Khem



More information about the uClibc mailing list