Xen devel - Mar 2009 - determining if a backend device is not working

In my gplpv drivers, the best I have come up with to determine if the
backend is not working is to wait for a few seconds (30 currently), and
if the backend state hasn''t changed by then then I assume that
it''s
broken.

Is there a better way? The situation where this comes up is when
something like '',hdc:cdrom,r'' is specified in the config file.

Even though I set all of the frontend up, the backend just stays at
state 2 instead of transitioning to 4.

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Is there a better way? The situation where this comes up is when
> something like '',hdc:cdrom,r'' is specified in the config
file.
>   
I have meet the same issue as yours. What I have done for that is to 
check device backend ''params'' key. If
'',hdc:cdrom,r'' in config file,
''params'' key should be null.

Also hope some other effective method.

thanks
wayne

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/03/2009 01:46, "James Harper"
<james.harper@bendigoit.com.au> wrote:
> In my gplpv drivers, the best I have come up with to determine if the
> backend is not working is to wait for a few seconds (30 currently), and
> if the backend state hasn''t changed by then then I assume that
it''s
> broken.
> 
> Is there a better way? The situation where this comes up is when
> something like '',hdc:cdrom,r'' is specified in the config
file.
> 
> Even though I set all of the frontend up, the backend just stays at
> state 2 instead of transitioning to 4.
I think we expect backends to always be responsive. So we have no model for
what to do if that assumption breaks. Your particular example above sounds
like a weird backend bug?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> On 10/03/2009 01:46, "James Harper"
<james.harper@bendigoit.com.au>
wrote:
> 
> > In my gplpv drivers, the best I have come up with to determine if
the
> > backend is not working is to wait for a few seconds (30 currently),
and
> > if the backend state hasn''t changed by then then I assume
that it''s
> > broken.
> >
> > Is there a better way? The situation where this comes up is when
> > something like '',hdc:cdrom,r'' is specified in the
config file.
> >
> > Even though I set all of the frontend up, the backend just stays at
> > state 2 instead of transitioning to 4.
> 
> I think we expect backends to always be responsive. So we have no
model
> for
> what to do if that assumption breaks. Your particular example above
sounds
> like a weird backend bug?
> 
A block device definition of '',hdc:cdrom,r'' appears to be
valid on the
qemu side of things. You just ''xm block-configure'' it when you
want to
''insert'' a cdrom image into it.

Blkback appears to not handle such things though, so it would have been
nice to quickly detect that blkback wasn''t doing anything useful and
just move on...

Oh well.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/03/2009 09:21, "James Harper"
<james.harper@bendigoit.com.au> wrote:
>> I think we expect backends to always be responsive. So we have no
> model
>> for
>> what to do if that assumption breaks. Your particular example above
> sounds
>> like a weird backend bug?
>> 
> 
> A block device definition of '',hdc:cdrom,r'' appears to be
valid on the
> qemu side of things. You just ''xm block-configure'' it
when you want to
> ''insert'' a cdrom image into it.
> 
> Blkback appears to not handle such things though, so it would have been
> nice to quickly detect that blkback wasn''t doing anything useful
and
> just move on...
So blkback currently just clams up in this case and won''t let you
connect at
all? I wonder if perhaps blkback isn''t even configured in this case...
Hmmm.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel