Am 23.04.2015 um 11:26 hat Paolo Bonzini geschrieben: > > > On 23/04/2015 11:00, Kevin Wolf wrote: > > Because it may be the right design. > > > > If you're really worried about the test matrix, put a check in the > > filter block driver that its bs->file is qcow2. Of course, such an > > artificial restriction looks a bit ugly, but using a bad design just > > in order to get the same restriction is even worse. > > > > Stefan originally wanted to put image streaming in the QED driver. I > > think we'll agree today that it was right to reject that. It's simply > > not functionality related to the format. Adding replication logic to > > qcow2 looks similar to me in that respect. > > Yes, I can't deny it is similar. Still, there is a very important > difference: limiting colo's internal workings to qcow2 or NBD doesn't > limit what the user can do (while streaming limited the user to image > files in QED format). > > It may also depend on how the patches look like and how much the colo > code relies on other internal state. > > For NBD the answer is almost nothing, and you don't even need a filter > driver. You only need to separate sharply the "configure" and "open" > phases. So it may indeed be possible to generalize the handling of the > secondary to non-NBD. > > It may be the same for the primary; I admit I haven't even tried to read > the qcow2 patch, as I couldn't do a meaningful review.
The qcow2 patch only modifies two existing lines. The rest it adds is a the qcow2+colo BlockDriver, which references some qcow2 functions directly and has a wrapper for others. On a quick scan, it didn't seem like it accesses any internal qcow2 variables or calls any private functions. In other words, it's the perfect example for a filter. Kevin
