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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home