On Thu, Jan 01, 2004 at 03:12:39PM -0500, Greg A. Woods wrote:
> > > Then, if you alter resolv.conf, run a program announcing "I've altered
> > > resolv.conf" to the world and all will be well! :)
> > 
> > This touches on a general problem that exists in all the free Unices:
> > user <-> kernel communication. There is simply no general, event based
> > infrastructure to communicate changes in the system state.
> 
> Huh?  /etc/resolv.conf edits are not kernel related.  There's no kernel
> state change to communicate.

Granted. But it _is_ an important, system wide, change in state.

> This is only a userland to userland issue.  SIGHUP is your friend.

SIGHUP is a blunt weapon: a process that recieves SIGHUP has no idea
what changed until it repolls all of it's configuration data.

Also, most interactive processes do not respond that way to SIGHUP at
all: they quit instead! I believe this is the historically correct way 
to behave.

> [interesting piece on OS theory and ioctls()]

This is all true, but beside the point. What I'm advocating is something 
like this:

A new char device, (say /dev/sysevent). An interested process open's
this and then select's on it (or uses kqueue). Then, when interesting
things happen (device add/remove, network link up/down, etc.), the
processes in question recieve a message telling them so, and they
take the appropriate action.

A process with sufficient priviliges would be able to write events to
the file, to notify of system-wide, non-kernel changes in state (like
/etc/resolv.conf changing).

We could then solve this specific problem by having the resolver use
kqueue to test /dev/sysevent for a new resolv.conf, and reload it
if so.

> Is [NIH syndrome] contagious or something?

NIH! NIH! NIH! 

And besides, didn't I just read you vaguely complain about TNF's "ultra-
conservative approach to things like this?" Where "this" is an entirely
new regex library?

-- 
Bruce J.A. Nourish <bjan+public@bjan.net> http://bjan.freeshell.org