On Thu, Aug 25, 2005 at 01:18:56PM +1000, Rusty Russell wrote:
> On Wed, 2005-08-24 at 09:25 +0100, Christian Limpach wrote:
> > On 8/24/05, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> > > The trace file is actually better in my experience. Also look for
> > > "error" nodes in the store (although Christian removed some of those
> > > paths in the merge).
> >
> > I only removed the ones which were not fatal because I was under the
> > impression initally that adding an error node does indicate a final
> > error after which it would be up to a control tool to sort out the
> > failure or report it.
>
> Well, I expect there to be an error node at some point in the normal
> case: you look in the backend and something isn't there yet, you want to
> indicate that, because it may never change (in the normal case, it will
> appear soon and we will delete the error node).
>
> 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, ...).
I don't like the idea of a status node since eventually it would get
out of sync, while the setup/error nodes indicate a state the driver
is in and won't get out of without it doing something actively.
christian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home