Re: [Xen-devel] [PATCH 4 of 7 v2] blktap3/tapback: Introduce back-end XenStore path handler

[Thanos Makatos <thanos.makatos@xxxxxxxxxx>]

> >
> > * Function tapback_backend_handle_backend_watch calls
> tapback_backend_scan
> >   even when we know in which domain a device changed, wouldn't it
> make sense
> >   from a performance perspective to only probe the devices of that
> domain
> >   instead of probing ALL devices of ALL domains?
> 
> I suppose it would...

The question is, could we leave this for later as an optimisation or should it 
be done in this patch series?

> 
> > * Is there a race condition between the tapback daemon and the
> toolstack
> >   regarding partially brought up devices? I'm trying to figure out
> what the
> >   "serial" thing does (check functions tapback_backend_create_device
> and
> >   tapback_backend_probe_device) but I don't get it. Even if there is
> such a
> >   race condition, I'm not convinced that the way that "serial" thing
> is
> >   implemented fixes it.
> 
> There isn't a "serial thing" in the generic protocol so I don't know
> what that is but normally the toolstack will write the entire initial
> backend/frontend directories in xenstore in a single transaction.
> 
> Also I think it is customary for backends to ignore directories with no
> "state" node -- and toolstacks write that last.
> 
> (Having now seen the serial stuff you refer I've no idea WTF it is
> trying to do either ;-))
> 

Then I suppose it's ok to completely remove this thing.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel