Re: [Qemu-devel] [PATCH] Further tidy-up on block status

[Alex Bligh]

> On 27 Dec 2016, at 14:09, Vladimir Sementsov-Ogievskiy <address@hidden> wrote:
> 
> What was the reason for it? Why not to negotiate forced structured read 
> separately? Actually, this spec forces any server, which wants to implement 
> structured reply implement structured read too. But what if it don't want to? 
> If it only wants to implement BLOCK_STATUS?
> 
> So, what about changing it, to allow BLOCK_STATUS (or other future structured 
> replies) without structured read? Structured read is good only for sparse 
> formats, when BLOCK_STATUS is more global. I understand, that servers may 
> implement simple (and useless) one-chunk structured read, but I think that it 
> is better to fix the spec, to not provoke servers use such workaround.

In essence the current reply format is broken, because it does not provide a 
means of delivering an error mid reply AND expects fixed length replies. Block 
Status is the poster child for something that benefits from structured replies.

So, BLOCK_STATUS requires structured replies. We thus have the choice between:
* Allowing structured replies to be implemented on a per-command basis
* Mandating that if structured replies are implemented, they are implemented 
universally

The second option is far simpler, and is what the current structured reply 
extension sets out. It's also a good nudge to server implementers (me included) 
to implement structured replies.

Your assumption that structured replies are only good for sparse formats is 
incorrect. It's good for anything that wants to include sensible error 
handling. As a server author, error handling at the moment is a pain. Most of 
us ALREADY break up large read requests (to avoid malloc() of huge amounts of 
memory), so we already have a read loop. If we don't then the 'one chunk' 
method is perfectly acceptable. If I implemented structured replies at all, I'd 
be sharing the code between multiple users in any case.

-- 
Alex Bligh