All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
Cc: Arun Sharma <arun.sharma@intel.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: Re: Timeout connecting to device
Date: Fri, 26 Aug 2005 10:27:06 +1000	[thread overview]
Message-ID: <1125016027.9945.45.camel@localhost.localdomain> (raw)
In-Reply-To: <20050825110117.GD13781@cl.cam.ac.uk>

On Thu, 2005-08-25 at 12:01 +0100, Christian Limpach wrote:
> On Thu, Aug 25, 2005 at 01:18:56PM +1000, Rusty Russell wrote:
> > The error node idea might be overly simplistic: its non-existence
> > doesn't tell you the device is ok (it might have just been created).
> > Makes it harder to synchronously create a device.
> 
> I think we need a setup node which indicates that a driver is stuck
> because it's waiting for a change in the store but that it expects
> this change to happen once the other party makes progress.  This would
> get set when the other party's directory doesn't exist yet or there
> are still nodes missing.
> The error node should indicate a final failure, where intervention
> by the control tool will be required.  This would get set when you
> read a value and can't parse it (not a number, not a mac address, ...)
> or when the information you've read is incorrect (ring reference can't
> be mapped, event channel can't connect, ...).

A slight variation on this would be to have the tools create the
"setting-up" node, and the driver delete it when it's happy.

I want to leave the error node on every error, so that way you can tell
if it can't read the backend because of permission problem or something,
even if during setup.

Synchronous startup is now fairly easy: wait for the setting-up node to
be deleted.  Monitoring status during startup is also fairly easy, by
watching the error node.  And the absence of both means we're happy and
live.

Thoughts?
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

  reply	other threads:[~2005-08-26  0:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-22 20:41 Timeout connecting to device Arun Sharma
2005-08-22 20:42 ` Arun Sharma
2005-08-24  1:36 ` Arun Sharma
2005-08-24  4:43   ` Rusty Russell
2005-08-24  8:25     ` Christian Limpach
2005-08-25  3:18       ` Rusty Russell
2005-08-25 11:01         ` Christian Limpach
2005-08-26  0:27           ` Rusty Russell [this message]
2005-08-26 10:37             ` Christian Limpach
2005-08-29  0:17               ` Rusty Russell
2005-08-29  0:23                 ` Christian Limpach
2005-08-25  0:31     ` Arun Sharma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1125016027.9945.45.camel@localhost.localdomain \
    --to=rusty@rustcorp.com.au \
    --cc=Christian.Limpach@cl.cam.ac.uk \
    --cc=arun.sharma@intel.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.