[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] slirp: Read host DNS config on demand
From: |
Jamie Lokier |
Subject: |
Re: [Qemu-devel] [PATCH] slirp: Read host DNS config on demand |
Date: |
Mon, 3 Aug 2009 14:30:08 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
Ed Swierk wrote:
> On Sun, Aug 2, 2009 at 8:03 AM, Jan Kiszka<address@hidden> 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