Re: [Qemu-devel] [PATCH] slirp: Read host DNS config on demand

[Jamie Lokier <jamie@shareable.org>]

Ed Swierk wrote:
> On Sun, Aug 2, 2009 at 8:03 AM, Jan Kiszka<jan.kiszka@web.de> wrote:
> > IMHO, 10 s is below the user surprise threshold for a dynamically
> > changing network link. Moreover, inotify does not exist on all platforms.
> >
> > Let's keep things simple for the first step, we could still further
> > improve it later on. 10 s are already an improvement over the current
> > infinite timeout.
> 
> Right. The most common situation in which the DNS server address
> changes is after you wake up your laptop and wait for it to connect to
> a new network. DHCP itself can take several seconds to do its thing,
> so you're unlikely to notice the up-to-10-second delay before full
> network connectivity is restored in a VM.

I strongly disagree.  Usual practice is to watch the NetworkManager
icon until it indicates that DHCP is complete with a green light,
finger poised over the clicking button, and then expect web browsing
and SSH to work immediately after the green light appears.  A 10
second delay at that point would be most irritating.

Ideally, that's what RTNETLINK events are for: you can register for
asynchronous events whenever a network interface is reconfigured, and
trigger things like rereading /etc/resolv.conf from that.  Windows has
a similar mechanism for watching interface changes.

But a 1/2 second delay would be fine.

> Of course there's nothing magical about 10 seconds. A shorter timeout
> would be even nicer, and I doubt anyone would really miss the CPU
> cycles lost to re-reading a tiny text file, but I don't think
> instantaneous response is required here.

All you need is to call stat() to confirm that the file hasn't
changed.  Just check the dev/ino/mtime/size.

If that were a periodic 1 second timer, the biggest cost on a laptop
might be power drain due to CPU wakeups.  But since the resolv.conf
check should only should be done in reaction to the VM actively doing
a DNS query (plus 1 second has passed since the last resolve.conf
check), the CPU is already woken up, so it's cheap.

-- Jamie