[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> >
> > * 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.