Am 28.05.2015 um 21:41 hat Eric Blake geschrieben: > On 05/28/2015 09:23 AM, Max Reitz wrote: > > >>>> Can we mark the parameter optional, and only provide it when it is > >>>> non-zero? That way, qemu-img (which cannot set an interval) will not > >>>> report it, and the only time it will appear is if it was set as part > >>>> of opening the block device under qemu. > >>> That sounds good. > >> But what do we do with the other parameters (refcount-cache-size, > >> l2-cache-size)? We cannot have the same solution there because they > >> don't belong to the image file either, and they're never going go be > >> zero. > > > > Pssht, don't mention it, or Eric will notice. :-) > > > > Well, one solution would be to remember whether they have been set > > explicitly or not. But that gets ugly really quickly. Maybe Kevin's > > series helps there, but I don't know. > > > > Of course, the simplest solution is to worry about cache-clean-interval > > for now and worry about the cache sizes later… But that basically means > > "We'll never worry about them unless someone complains", so… > > Hmm, now that we have three pieces of data, I'm starting to lean more > towards ImageInfoSpecific being the wrong place for this after all; it > would still be nice to advertise all three, but where? Is > BlockdevCacheInfo more appropriate (as a sub-struct of BlockDeviceInfo)?
BlockDeviceInfo contains runtime information, so that looks like the right place indeed. As these options aren't present for all devices, I don't think we should extend BlockdevCacheInfo, but rather introduce a BlockDeviceInfoSpecific that works like ImageInfoSpecific, just for runtime information. I agree with Berto that that's out of scope for this series, though. Kevin
pgphZf465jHvw.pgp
Description: PGP signature
