Re: [PATCH] iphlpapi: Retrieve DNS servers from /etc/resolv.conf if possible
On Tue, Jan 31, 2017 at 1:36 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote:
Tested on FreeBSD 10 and PC-BSD 9 where it gives me the unimplemented message (and Debian by changing some defines). ...
Is the purpose of this to provide a fallback implementation or to get FreeBSD 10 and PC-BSD 9 working? From a quick googling it looks like FreeBSD and PC-BSD both should support __res_getservers, though NetBSD seems to use res_getservers. Are you possibly missing a header (or are we failing to include a header)? Best, Erich
On Wed, Feb 8, 2017 at 11:59 AM, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote:
On Tue, Jan 31, 2017 at 1:36 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote:
Tested on FreeBSD 10 and PC-BSD 9 where it gives me the unimplemented message (and Debian by changing some defines). ...
Is the purpose of this to provide a fallback implementation or to get FreeBSD 10 and PC-BSD 9 working? From a quick googling it looks like FreeBSD and PC-BSD both should support __res_getservers, though NetBSD seems to use res_getservers. Are you possibly missing a header (or are we failing to include a header)?
I do have /usr/include/resolv.h but none of the #defines required in iphlpapi_main.c are met. And I still think it can act as a fallback for overly restrictive systems on embedded platforms. Thanks for the review, Bruno
On Wed, Feb 8, 2017 at 8:20 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote:
... I do have /usr/include/resolv.h but none of the #defines required in iphlpapi_main.c are met.
Would you mind sending me your config.log? It seems odd to me that __res_get_state and __res_getservers would be unavailable, maybe a missing linker option? It would also be interesting to see if res_get_state and res_getservers exist on your test system.
And I still think it can act as a fallback for overly restrictive systems on embedded platforms.
I think that could make sense, but we probably want to emit some kind of warning if that's the case - otherwise we will never find out about problems like the one it seems like you've encountered.
Thanks for the review,
No problem! Best, Erich
On Wed, Feb 08, 2017 at 08:50:47AM -0700, Erich E. Hoover wrote:
On Wed, Feb 8, 2017 at 8:20 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote:
... I do have /usr/include/resolv.h but none of the #defines required in iphlpapi_main.c are met.
Would you mind sending me your config.log? It seems odd to me that __res_get_state and __res_getservers would be unavailable, maybe a missing linker option? It would also be interesting to see if res_get_state and res_getservers exist on your test system.
And I still think it can act as a fallback for overly restrictive systems on embedded platforms.
I think that could make sense, but we probably want to emit some kind of warning if that's the case - otherwise we will never find out about problems like the one it seems like you've encountered.
If this does go in, we'll want some kind of caching. Huw.
On Thu, Feb 9, 2017 at 1:52 AM, Huw Davies <huw(a)codeweavers.com> wrote:
... If this does go in, we'll want some kind of caching.
It looks like our existing code should actually be able to handle the case Bruno is interested in, our configure test is just missing some headers. Bruno is looking into it a little bit more, but I think the manual parsing can be avoided (at least, for the case he's interested in). Best, Erich
On Thu, Feb 9, 2017 at 12:15 PM, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote:
On Thu, Feb 9, 2017 at 1:52 AM, Huw Davies <huw(a)codeweavers.com> wrote:
... If this does go in, we'll want some kind of caching.
The other places using fopen (ifstats.c) don't use caching, that was where I based the idea on. Due to the nature of network configuration I'm not sure it is a good idea, for example, when to renew the cache?
It looks like our existing code should actually be able to handle the case Bruno is interested in, our configure test is just missing some headers. Bruno is looking into it a little bit more, but I think the manual parsing can be avoided (at least, for the case he's interested in).
I still think the patch is useful and would like to see it commited independent of the FreeBSD stuff. I'll resend in a series with the FreeBSD configure.ac change with a few extra traces to ensure it is not used wrongly.
On Thu, Feb 09, 2017 at 01:28:28PM -0200, Bruno Jesus wrote:
On Thu, Feb 9, 2017 at 12:15 PM, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote:
On Thu, Feb 9, 2017 at 1:52 AM, Huw Davies <huw(a)codeweavers.com> wrote:
... If this does go in, we'll want some kind of caching.
The other places using fopen (ifstats.c) don't use caching, that was where I based the idea on.
Those places are reading virtual files which whose contents are expected to change.
Due to the nature of network configuration I'm not sure it is a good idea, for example, when to renew the cache?
Generally /etc/resolv.conf doesn't change much, of course this is not so true with mobile devices. glibc reads this when you call res_init(). I guess if you really wanted to you could let the file be re-read every 5 seconds or so, but not every time the dns server list is queried. Huw.
On Thu, Feb 9, 2017 at 2:12 PM, Huw Davies <huw(a)codeweavers.com> wrote:
On Thu, Feb 09, 2017 at 01:28:28PM -0200, Bruno Jesus wrote:
On Thu, Feb 9, 2017 at 12:15 PM, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote:
On Thu, Feb 9, 2017 at 1:52 AM, Huw Davies <huw(a)codeweavers.com> wrote:
... If this does go in, we'll want some kind of caching.
The other places using fopen (ifstats.c) don't use caching, that was where I based the idea on.
Those places are reading virtual files which whose contents are expected to change.
Due to the nature of network configuration I'm not sure it is a good idea, for example, when to renew the cache?
Generally /etc/resolv.conf doesn't change much, of course this is not so true with mobile devices. glibc reads this when you call res_init(). I guess if you really wanted to you could let the file be re-read every 5 seconds or so, but not every time the dns server list is queried.
I'll do that then, better than discard the patch IMHO.
Bruno Jesus <00cpxxx(a)gmail.com> writes:
On Thu, Feb 9, 2017 at 2:12 PM, Huw Davies <huw(a)codeweavers.com> wrote:
On Thu, Feb 09, 2017 at 01:28:28PM -0200, Bruno Jesus wrote:
On Thu, Feb 9, 2017 at 12:15 PM, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote:
On Thu, Feb 9, 2017 at 1:52 AM, Huw Davies <huw(a)codeweavers.com> wrote:
... If this does go in, we'll want some kind of caching.
The other places using fopen (ifstats.c) don't use caching, that was where I based the idea on.
Those places are reading virtual files which whose contents are expected to change.
Due to the nature of network configuration I'm not sure it is a good idea, for example, when to renew the cache?
Generally /etc/resolv.conf doesn't change much, of course this is not so true with mobile devices. glibc reads this when you call res_init(). I guess if you really wanted to you could let the file be re-read every 5 seconds or so, but not every time the dns server list is queried.
I'll do that then, better than discard the patch IMHO.
If you have fixed the issue for BSD, I don't see much point in having the fallback. If there's really a system that doesn't have the resolver, it's not clear that it would use resolv.conf either. I'd wait until we find a demonstrated need. -- Alexandre Julliard julliard(a)winehq.org
On Thu, Feb 09, 2017 at 02:44:01PM -0200, Bruno Jesus wrote:
On Thu, Feb 9, 2017 at 2:12 PM, Huw Davies <huw(a)codeweavers.com> wrote:
On Thu, Feb 09, 2017 at 01:28:28PM -0200, Bruno Jesus wrote:
On Thu, Feb 9, 2017 at 12:15 PM, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote:
On Thu, Feb 9, 2017 at 1:52 AM, Huw Davies <huw(a)codeweavers.com> wrote:
... If this does go in, we'll want some kind of caching.
The other places using fopen (ifstats.c) don't use caching, that was where I based the idea on.
Those places are reading virtual files which whose contents are expected to change.
Due to the nature of network configuration I'm not sure it is a good idea, for example, when to renew the cache?
Generally /etc/resolv.conf doesn't change much, of course this is not so true with mobile devices. glibc reads this when you call res_init(). I guess if you really wanted to you could let the file be re-read every 5 seconds or so, but not every time the dns server list is queried.
I'll do that then, better than discard the patch IMHO.
Well I'm not convinced we want to bloat the code just in case some, as yet undiscovered, system doesn't come with one of the existing mechanisms which we do handle. I'd just get the configure fixes in and stop working on the fallback. Huw.
Well I'm not convinced we want to bloat the code just in case some, as yet undiscovered, system doesn't come with one of the existing mechanisms which we do handle. I'd just get the configure fixes in and stop working on the fallback.
No problem, I'll hold it for the day it is required ;-)
participants (4)
-
Alexandre Julliard -
Bruno Jesus -
Erich E. Hoover -
Huw Davies