[systemd-devel] [RFC 3/6] proxy-discoveryd: Add PAC support through duktape js engine

[Tomasz Bursztyka]

Hi Tom,

>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -5895,12 +5895,19 @@ rootlibexec_PROGRAMS += \
>>          systemd-proxy-discoveryd
>>
>>   systemd_proxy_discoveryd_SOURCES = \
>> +       src/proxy-discovery/duktape.h \
>> +       src/proxy-discovery/duktape.c \
> These files are not included in the patch, how do you intend to ship them?

I figured this could be included as a separate commit, when it will be 
time to commit proxy-discoveryd someday.
Those 2 files represent more than 2 megabytes, so I did not want to 
flood the ml.

>
>>          src/proxy-discovery/proxy-discoveryd.c \
>>          src/proxy-discovery/proxy-discoveryd.h \
>>          src/proxy-discovery/proxy-discoveryd-manager.c \
>> +       src/proxy-discovery/proxy-discoveryd-pac.c \
>>          src/proxy-discovery/proxy-discoveryd-proxy.c \
>>          src/proxy-discovery/proxy-discoveryd-proxy-gperf.c
>>
>> +systemd_proxy_discoveryd_CFLAGS = \
>> +       $(AM_CFLAGS) \
>> +       -fno-fast-math
> Hm, what's this all about?

duktape refuses to compile with fast-math directive. It can be forced 
however.
I just avoided it for the PoC.

>> +        }
>> +
>> +        address->in = ((struct sockaddr_in *) &ifr.ifr_addr)->sin_addr;
>> +
>> +        close(sk);
>> +
>> +        return 0;
>> +}
> The above function is fine as part of a prototype, but for the final
> version we should use rtnl like everywhere else, no?

Yep, I only did that for a working PoC. But rtnl based logic should be 
the way to go.


I'll apply the return code comments.

Tomasz