[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCHv2 6/7] cleanup qemu_co_sendv(), qemu_co_recvv()
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCHv2 6/7] cleanup qemu_co_sendv(), qemu_co_recvv() and friends |
Date: |
Mon, 12 Mar 2012 17:50:45 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 |
Il 12/03/2012 17:29, Michael Tokarev ha scritto:
>> For example, qemu_co_recvv has handling for receiving 0, but
>> > qemu_co_sendv does not.
> This is a bug, which I dind't notice, it shouldn't
> be there. Somehow I overlooked this difference, but
> I really wondered how they're differ! By using common
> code here it becomes much more obvious (whith the bug
> actually fixed).
write should never return 0, read does for end-of-file.
So your code was actually correct in some sense.
>> This is what I don't really like in the second part of these patches.
>> You are doing changes for the sake of other changes which are not
>> upstream yet, for which there is no clear vision, and for which there is
>> no clear benefit.
> I already posted the example of this. I can complete whole thing
> and send it all in one huge chunk if you prefer that
>
>> While I agree that there is a lot of duplicated code in block.c and
>> block/*, I don't think that what we need is more parameters to the
>> functions. We have places where we need to know the request flags, for
>> example, but the methods are already quite unwieldy and have a lot of
>> arguments. So I'm not sure that this kind of unification buys anything.
> Which places are these?
If we turn zero-write into a special case of discard, we will need it as
a flag in discard. Block mirroring would like to have access to
copy-on-read flags.
> Also, how about dropping nr_sectors?
>
> If you need flags, well, the extra argument being
> added can really be used for that if necessary.
Or we can actually clean up everything, and create a real "request"
structure that can be passed along. See how flush and discard are
really similar (which do not have all the accumulated stuff for
throttling, copy-on-read, bounce buffering, etc.). Perhaps that's the
place to start.
Paolo
- [Qemu-devel] [PATCHv2 1/7] Consolidate qemu_iovec_memset{, _skip}() into single, simplified function, (continued)
- [Qemu-devel] [PATCHv2 1/7] Consolidate qemu_iovec_memset{, _skip}() into single, simplified function, Michael Tokarev, 2012/03/10
- [Qemu-devel] [PATCHv2 2/7] allow qemu_iovec_from_buffer() to specify offset from which to start copying, Michael Tokarev, 2012/03/10
- [Qemu-devel] [PATCHv2 7/7] rewrite and comment qemu_sendv_recvv(), Michael Tokarev, 2012/03/10
- [Qemu-devel] [PATCHv2 4/7] change prototypes of qemu_sendv() and qemu_recvv(), Michael Tokarev, 2012/03/10
- [Qemu-devel] [PATCHv2 6/7] cleanup qemu_co_sendv(), qemu_co_recvv() and friends, Michael Tokarev, 2012/03/10
- Re: [Qemu-devel] [PATCHv2 6/7] cleanup qemu_co_sendv(), qemu_co_recvv() and friends, Paolo Bonzini, 2012/03/11
- Re: [Qemu-devel] [PATCHv2 6/7] cleanup qemu_co_sendv(), qemu_co_recvv() and friends, Michael Tokarev, 2012/03/11
- Re: [Qemu-devel] [PATCHv2 6/7] cleanup qemu_co_sendv(), qemu_co_recvv() and friends, Paolo Bonzini, 2012/03/12
- Re: [Qemu-devel] [PATCHv2 6/7] cleanup qemu_co_sendv(), qemu_co_recvv() and friends, Michael Tokarev, 2012/03/12
- Re: [Qemu-devel] [PATCHv2 6/7] cleanup qemu_co_sendv(), qemu_co_recvv() and friends,
Paolo Bonzini <=
[Qemu-devel] [PATCHv2 3/7] consolidate qemu_iovec_copy() and qemu_iovec_concat() and make them consistent, Michael Tokarev, 2012/03/10
Re: [Qemu-devel] [PATCHv2 0/7] cleanup/consolidate some iovec functions, Michael Tokarev, 2012/03/10
Re: [Qemu-devel] [PATCHv2 0/7] cleanup/consolidate some iovec functions, Paolo Bonzini, 2012/03/11