[ On Tuesday, January 6, 2004 at 14:59:53 (-0800), Jason Thorpe wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
>
> 
> I then challenge you to look it at another way.  Just because something 
> is defined in a system header file does not mean it is for consumption 
> by random external users of a given API.

(a) we're not talking about random external users

We're talking about code that's in libc and is just one logical layer
above the resover(3) API, though if you've taken a look at any of the
get*() routines in the resolver are actually implemented then you'll
have hopefully noticed that they already dig quite deep into the guts of
the underlying res_*() implementation in order to avoid calling
res_init() more than once per process.  I.e. your wish to avoid layering
violations was made impossible over a decade ago, and cleaning it up is
not something NetBSD should attempt alone (and I'm not sure anyone
should bother -- these are highly interdependent routines and if we hope
to ever resolve the debate about nsswitch vs. ISC IRS so that the
resolver code in NetBSD can eventually be upgraded and made to more
easily track the ISC BIND lwres code then NetBSD is definitely not going
to be able to solve this issue on its own).

>  (The macro in question is out 
> of the user namespace, after all...)

(b) we're not talking about the user namespace.

We're talking about what's already libc's and the resolver's very own
private namespace, and by "resolver" I'm including both gethostby*() and
resolver(3) since they're already intimately intertwined in their
current implementation.

> Applications and library routines outside the core resolver code 
> currently have no reason to care of the existence of the resolv.conf 
> file, whether or not the _PATH_RESCONF macro is defined by a system 
> header file.

(c) in essense we're not talking about anything _but_ the core resolver
code.

(except for the intervention nsswitch makes for nefarious purposes of
bypassing the underlying DNS)

In fact it's res_init() itself that has a well documented and well known
public API and it is the semantics of that routine that I've been
arguing to protect all along, in case you hadn't realized.  What I've
been trying to show is that res_init() _IS_ the defined way that the
lowest layer resolver routines are to be initialized and that it's the
responsibility of the gethost*() layer directly above to determine when
to call res_init().  Currently they do so by testing to see if the
RES_INIT bit has been turned on in _res.options -- augmenting that test
with comparing the results of a previous and current stat(_PATH_RESCONF)
is the only logical way to meet the goal Manuel set out to chase.

> Finally, also consider that some software that is based on NetBSD might 
> use alternate configuration mechanisms (configuration files are 
> sometimes hokey in embedded systems).  Right now resolv.conf handling 
> is nicely contained in one place, which makes it easy to glue in 
> alternate configuration mechanisms.  If you suddenly sprinkle 
> resolv.conf handling all over the place, you've now made it more 
> difficult for users of the NetBSD code base to glue in alternate 
> configuration schemes.

(d) I'm not talking about sprinkling resolv.conf handling "all over the
place", and I don't think anyone else is either.

We're talking about putting it one of two highly resolver related
locations.

Given the way NetBSD's nsswitch shims itself into the gethostby*()
implementation in such a way that the underlying resolver(3) routines
may not be used in a given runtime configuration it would seem quite
logical to add an "init" hook as has been suggested since that would
avoid the overhead of ever trying to initialize the resolver(3) layer if
it's not going to be used in a given runtime environment.

However I think that would be quite a shakeup in the way nsdispatch() is
used internally so perhaps for now the logical thing to do is simply
throw the stat(_PATH_RESCONF) checks in front of each call to res_init()
and ignore the _res.options&RES_INIT test if the stat() results change.

I.e. it'll still be just as trivial for you, or whomever you're refering
to, to hack your alternate configuration mechanism into just one place.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>