[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH net-next 2/2] xen-netback: handle frontends that fail to transition through Closing
On Fri, Sep 20, 2013 at 02:38:46PM +0100, David Vrabel wrote: > On 20/09/13 14:34, Wei Liu wrote: > > On Fri, Sep 20, 2013 at 01:56:31PM +0100, Paul Durrant wrote: > >> Some old Windows frontends fail to transition through the xenbus Closing > >> state and move directly from Connected to Closed. Handle this case > >> properly. > >> > >> --- a/drivers/net/xen-netback/xenbus.c > >> +++ b/drivers/net/xen-netback/xenbus.c > >> @@ -265,6 +265,8 @@ static void frontend_changed(struct xenbus_device *dev, > >> break; > >> > >> case XenbusStateClosed: > >> + if (dev->state == XenbusStateConnected) > >> + disconnect_backend(dev); > > > > Could you please add a comment above this change stating that this is a > > workaround for some old frontend that we cannot fix / upgrade. > > Handling frontend CONNECTED -> CLOSED is a sensible thing for a backend > to do regardless of whether there are old frontends that do this or not. > I agree handling connected -> closed is sensible here based on the fact that old frontends could do such state change. However If the state machine was documented well enough then I think connected -> closed would not be considered sensible. This code snippet without comment will cause confusion / encourage wrong usage of state machine if someone comes here for reference. > > We would still like to later frontend goes through the normal connected > > -> closing -> closed path. > > This should be documented as a full description of the two state > machines in public/io/netif.h in Xen. Not scattered about in comments Sure. > in a particular backend implementation. > The comment in implementation is still worthwhile in case someone comes here for reference and gets confused. Wei. > David _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |