[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH] Further tidy-up on block status
Date: Mon, 16 Jan 2017 15:26:51 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

13.01.2017 13:29, Alex Bligh wrote:
On 13 Jan 2017, at 09:48, Vladimir Sementsov-Ogievskiy <address@hidden> wrote:

12.01.2017 16:11, Alex Bligh wrote:
On 12 Jan 2017, at 07:05, Vladimir Sementsov-Ogievskiy <address@hidden> wrote:

Yes this is better. But is it actually needed to force contexts have some safe 
default? If context wants it may define such default without this requirement.. 
So, should it be requirement at all?
I've changed this to:

     of the file), a server MAY reply with a single block status
     descriptor with *length* matching the requested length, rather than
     reporting the error; in this case the context MAY mandate the
     status returned.

Hmm, I don't understand. So, it MAY mandate and therefore MAY NOT do it? And 
what client should think, if server replies with one chunk matching the request 
length and not mandate the status?
Some contexts may mandate a particular value (so for instance the allocation 
context might mandate 0).

Some contexts may not mandate a particular value, in which case the 
interpretation is dependent upon the context (just like any other status 
value). EG a context which returned an status of 7 if the range contained a 
prime number, and else 3, could carry on doing that.

As it doesn't make sense to interpret status returns without an understanding 
of the particular context, we might as well simply extend this to 'beyond the 
range' returns - as I think you pointed out!

>>> The status flags are intentionally defined so that a server MAY always safely report a status of 0 for any block

- Actually, status flags are _not_ defined. (each context defines it's own status flags)

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]