On Fri, 13 May 2011 16:13:55 +0200 Markus Armbruster <arm...@redhat.com> wrote:
> Luiz Capitulino <lcapitul...@redhat.com> writes: > > > On Fri, 13 May 2011 10:26:38 +0200 > > Markus Armbruster <arm...@redhat.com> wrote: > > > >> Luiz Capitulino <lcapitul...@redhat.com> writes: > >> > >> > On Thu, 12 May 2011 19:54:40 +0200 > >> > Markus Armbruster <arm...@redhat.com> wrote: > >> > > >> >> Luiz Capitulino <lcapitul...@redhat.com> writes: > >> >> > >> >> > On Thu, 12 May 2011 19:12:56 +0200 > >> >> > Markus Armbruster <arm...@redhat.com> wrote: > >> >> > > >> >> >> Luiz Capitulino <lcapitul...@redhat.com> writes: > [...] > >> >> >> > Also, we can't just drop it from QMP. We should first note it's > >> >> >> > deprecated. > >> >> >> > >> >> >> Would you accept a change to the more honest value "unknown" for the > >> >> >> deprecation period? > >> >> > > >> >> > We have to avoid breaking the protocol. Changing something that has > >> >> > always > >> >> > been reported as 'cdrom' to 'unknown' will likely cause as many as > >> >> > damages > >> >> > as dropping the command. > >> >> > >> >> I can cause damage only if somebody is using it. Which I doubt. > >> > > >> > Me too and I'd agree with this patch if I was 100% sure. But it's > >> > impossible > >> > to be sure, unless we do it by trial and error which is harmful. > >> > > >> >> Remember, the value is unreliable. It's a *lie*. We can stop lying in > >> >> two ways: shut up (drop member "type"), or tell the truth (change the > >> >> value to "unknown", which is a documented value of "type"). > >> > > >> > Can we set it to 'unknown' when if=none? > >> > >> Maybe. Makes query-block mix up host and guest information again. > > > > It's temporary, just to respect our deprecation policy and give us time > > to provide a viable alternative. > > > >> Purging guest information from block.c is the point of this series. > >> Therefore, query-block can't be done in block.c anymore. It needs to > >> move to blockdev.c, where the mixed-up-by-design DriveInfo is available. > >> It could move back when we finally clean up query-block. > >> > >> Even with such compatibility gymnastics, it could still break your > >> hypothetical client. > > > > Our deprecation policy is not hypothetical. There isn't case by case. Either > > we respect it or we don't. > > My point is: even your deprecation policy cannot protect your > hypothetical client. > > The only way to ensure not even the silliest hypothetical client breaks > is not to change anything. Which means we cannot fix query-block not to > lie about the type, period. Which means we have to deprecate > query-block wholesale to fix that bug. Why don't we force the known broken cases (like if=none) to 'unknown', note in the doc that the field is unreliable and specify that it can be dropped in 2 or 3 releases? > > Kevin, please apply patches 1+2+6. Feel free to drop 3-5. > > [...] >
