On 10/06/2017 02:34 AM, Vladimir Sementsov-Ogievskiy wrote:
>> - if the chunk is NBD_REPLY_TYPE_NONE, there is no payload, and this
>> should be the final chunk, so the return to the caller can be the same
>> as for old-style (return 1 if we had no earlier error packets, or the
>> saved negative v
06.10.2017 01:12, Eric Blake wrote:
On 10/05/2017 05:36 AM, Paolo Bonzini wrote:
On 05/10/2017 12:02, Vladimir Sementsov-Ogievskiy wrote:
03.10.2017 17:06, Paolo Bonzini wrote:
On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
In the end this probably means that you have a read_chunk_h
06.10.2017 10:09, Vladimir Sementsov-Ogievskiy wrote:
06.10.2017 01:12, Eric Blake wrote:
On 10/05/2017 05:36 AM, Paolo Bonzini wrote:
On 05/10/2017 12:02, Vladimir Sementsov-Ogievskiy wrote:
03.10.2017 17:06, Paolo Bonzini wrote:
On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
In t
06.10.2017 01:12, Eric Blake wrote:
On 10/05/2017 05:36 AM, Paolo Bonzini wrote:
On 05/10/2017 12:02, Vladimir Sementsov-Ogievskiy wrote:
03.10.2017 17:06, Paolo Bonzini wrote:
On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
In the end this probably means that you have a read_chunk_h
On 10/05/2017 05:36 AM, Paolo Bonzini wrote:
> On 05/10/2017 12:02, Vladimir Sementsov-Ogievskiy wrote:
>> 03.10.2017 17:06, Paolo Bonzini wrote:
>>> On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
>> In the end this probably means that you have a read_chunk_header
>> function and
On 05/10/2017 12:02, Vladimir Sementsov-Ogievskiy wrote:
> 03.10.2017 17:06, Paolo Bonzini wrote:
>> On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
> In the end this probably means that you have a read_chunk_header
> function and a read_chunk function. READ has a loop that calls
03.10.2017 17:06, Paolo Bonzini wrote:
On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
In the end this probably means that you have a read_chunk_header
function and a read_chunk function. READ has a loop that calls
read_chunk_header followed by direct reading into the QEMUIOVector,
whi
03.10.2017 17:06, Paolo Bonzini wrote:
On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
In the end this probably means that you have a read_chunk_header
function and a read_chunk function. READ has a loop that calls
read_chunk_header followed by direct reading into the QEMUIOVector,
whi
On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
>>>
>>> In the end this probably means that you have a read_chunk_header
>>> function and a read_chunk function. READ has a loop that calls
>>> read_chunk_header followed by direct reading into the QEMUIOVector,
>>> while everyone else calls
On 03/10/2017 14:26, Vladimir Sementsov-Ogievskiy wrote:
> 03.10.2017 13:07, Paolo Bonzini wrote:
>> On 26/09/2017 00:19, Eric Blake wrote:
+ /* here we deal with successful structured reply */
+ switch (s->reply.type) {
+ QEMUIOVector sub_qiov;
+ case NBD_SREP_T
03.10.2017 15:58, Vladimir Sementsov-Ogievskiy wrote:
03.10.2017 13:07, Paolo Bonzini wrote:
On 26/09/2017 00:19, Eric Blake wrote:
+ /* here we deal with successful structured reply */
+ switch (s->reply.type) {
+ QEMUIOVector sub_qiov;
+ case NBD_SREP_TYPE_OFFSET_DATA:
This i
03.10.2017 13:07, Paolo Bonzini wrote:
On 26/09/2017 00:19, Eric Blake wrote:
+/* here we deal with successful structured reply */
+switch (s->reply.type) {
+QEMUIOVector sub_qiov;
+case NBD_SREP_TYPE_OFFSET_DATA:
This is putting a LOT of smarts directly into the receive rou
03.10.2017 13:07, Paolo Bonzini wrote:
On 26/09/2017 00:19, Eric Blake wrote:
+/* here we deal with successful structured reply */
+switch (s->reply.type) {
+QEMUIOVector sub_qiov;
+case NBD_SREP_TYPE_OFFSET_DATA:
This is putting a LOT of smarts directly into the receive rou
On 26/09/2017 00:19, Eric Blake wrote:
>> +/* here we deal with successful structured reply */
>> +switch (s->reply.type) {
>> +QEMUIOVector sub_qiov;
>> +case NBD_SREP_TYPE_OFFSET_DATA:
> This is putting a LOT of smarts directly into the receive routine.
> Here's where I was pr
14 matches
Mail list logo
