This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Xen watchdog?

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen watchdog?
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 25 Sep 2007 18:34:12 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Richard W.M. Jones" <rjones@xxxxxxxxxx>
Delivery-date: Tue, 25 Sep 2007 10:34:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C31E9323.15EEA%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C31E9323.15EEA%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6
> I took a brief look at it. It was kind of big, with no great justification.
> I would have written a simple little user daemon for kicking the watchdog
> directly, rather than add extra stuff in our Linux kernel. But perhaps the
> latter is the 'proper' way? If so, the driver probably needs review on
> lkml.

It's the Linux Way - a userspace app wouldn't work, since it wouldn't be able 
to export the /dev/watchdog device node that HA infrastructure needs.

To be honest, IIRC, it seemed to me like most watchdog drivers in Linux could 
share more common code and then all be a decent bit smaller - something I 
could look at if the Linux folks are interested but wasn't on my todo list at 
the time.

A fair bit of the bulk in the rest of the code was in making the dom0 tools be 
a bit more aware of the watchdog state.  This was needed to support features 
such as the "watchdog initiated reboot" flag, but isn't strictly needed for 
basic functionality.  I can trim this bit out, at least for an initial merge, 
but there may be other stuff it'd be helpful to hook in here.

> Either way, I think the hypervisor interface should support multiple
> entities per guest trying to set up a watchdog timer. Even if just so that
> entities that lose the race get -EBUSY. This would make it safer to use
> without a single controlling entity in the guest kernel.

Hmmm.  I could do something like that, certainly.  The model I was following 
was that of hardware - I'm not sure what a physical watchdog card would do 
with multiple controlling entities but I doubt it'd be pretty.  As we're in 
the hypervisor, we've got more smarts available to us though, so a bit of 
opaque state to identify a "watchdog handle" should be trivial to add.  I 
wonder if there are any potential users this sort of behaviour, though - 
maybe Richard would comment here?

The only significant feature I'd want to add before merge is support for 
suspend / resume - that should be fairly simple to add, though.


Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>