[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/3] Combine bdrv_co_readv and bdrv_co_writev in
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 3/3] Combine bdrv_co_readv and bdrv_co_writev into bdrv_co_rw_vector |
Date: |
Wed, 29 Feb 2012 17:24:32 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 |
Il 29/02/2012 17:12, Michael Tokarev ha scritto:
> On 29.02.2012 20:01, Paolo Bonzini wrote:
>> Il 29/02/2012 00:54, Michael Tokarev ha scritto:
>>> BlockDriver *drv = bs->drv;
>>> BdrvTrackedRequest req;
>>> + bool is_write = flags & (BDRV_REQ_WRITE|BDRV_REQ_ZERO_WRITE);
>>> int ret;
>>
>> You can do BDRV_REQ_WRITE|BDRV_REQ_ZERO_WRITE, but not
>> BDRV_REQ_READ|BDRV_REQ_COPY_ON_READ. That's ugly.
>
> BDRV_REQ_READ is zero. This is just mnemonic to avoid "magic
> numbers" elsewhere in the code. This is an internal function
> and the comment above it says just that, and it is always
> called with just ONE value. It is not a bitmask, it is used
> as such inside this very routine ONLY. The argument is declared
> as enum too, -- this should tell something. In the function
> prototype it should have been named "opcode" or "request",
> not "flags". It is used as flags only inside this function.
>
> This code isn't written by me, it was this way before.
> I just added 2 more possible values for this parameter.
If you have 4 values, make them 1/2/4/8 or 0/1/2/3. Not 0/1/2/4.
> No block driver -- at least currently -- needs any other value
> here except of read-or-write (or is_write). COPY_ON_READ is
> not a business of the individual block drivers currently.
Sure, but ZERO_WRITES is (we have a separate callback).
> These defines are _only_ to make some code a bit more readable,
> in a very few places where it necessary to call individual
> read or write block driver method. So that the construct:
>
> ret - s->bdrv_co_rw_vector(bs, ..., true)
>
> becomes
>
> ret - s->bdrv_co_rw_vector(bs, ..., BDRV_WRITE)
>
> and it is immediately obvious that it is write. The prototype
> of the method has "bool is_write" here.
If you use an enum, the prototype shouldn't be bool.
>> But I'm skeptical, the
>> actual amount of unification is not that large.
>
> This is not about unification. This is, as described in the introduction
> email, about removing complexity of a very twisted nature of read and
> write code paths, for a start.
The patches are a balance of removing duplication and adding
conditionals, no? Removing duplication is unification.
Paolo