On 07/10/2017 08:50 AM, Kevin Wolf wrote: > We have regretted enough things that were defined a bit sloppily just > for convenience that I'd rather not make this mistake again when we can > avoid it.
Agreed. Another consideration: defining redundant information is trickier to maintain because correct implementations have to check that both points are consistent with one another. > >>>> + 17 - 19: Reserved for future use, must be zero. >>> We don't need this for now because byte 16 will be the final one in this >>> struct. >>> >>>> + 20 - 23: extra_data_size >>>> + Size of compress format specific extra data. >>>> + For now, as no format specifies extra data, >>>> + extra_data_size is reserved and should be zero. >>>> + >>>> + variable: extra_data >>>> + Extra data with additional parameters for the compress >>>> + format, occupying extra_data_size bytes. >>> extra_data_size isn't necessary because we already have the length of >>> the header extension, so we know how long the whole thing is. >>> extra_data isn't necessary because we'll just add new fields at the end >>> if we want to add something. >> >> I was asked to add it altough it is redundant. > > Who asked this, and did they have a good reason for it? May have been me, or may have been implied by my comments, but I agree that the overall extension header covers this, so we don't need a redundant form. So as long as the overall extension header length is good enough, I'm okay avoiding redundancies. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
