[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Timeout connecting to device
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |