qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] ide: Add resize callback to ide/core
Date: Thu, 14 Aug 2014 12:06:25 -0400	[thread overview]
Message-ID: <53ECDE81.7070401@redhat.com> (raw)
In-Reply-To: <87ha1fmto6.fsf@blackfin.pond.sub.org>



On 08/14/2014 03:12 AM, Markus Armbruster wrote:
>
> I'd prefer if (s->drive_kind == IDE_CFATA) ... else ..., because it
> avoids the double negative.

OK. This is how cmd_identify delegates. For matters of style I usually 
try to defer to nearby code.

>
> Your code duplicates the parts of the functions initializing
> s->identify_data dealing with nb_sectors.  These are:
>
> * ide_identify() for IDE_HD
>
>    Writes nb_sectors to slots 60..61 and 100..103.  Matches your code.
>
> * ide_atapi_identify() for IDE_CD
>
>    Doesn't use it at all.  Your code clobbers slots 60..61 and 100.103.
>    Oops.
>

ide_resize_cb does not get called for ATAPI drives, so I think this is 
not relevant. I tried to note this in a comment. See ide_init_drive:

     if (kind == IDE_CD) {
         bdrv_set_dev_ops(bs, &ide_cd_block_ops, s);
         ...
     } else {
         ...
         bdrv_set_dev_ops(bs, &ide_hd_block_ops, s);
     }


> * ide_cfata_identify() for IDE_CFATA
>
>    Writes nb_sectors to slots 7..8 and and 60..61.  Your code only writes
>    the former.

...Sorry. I appreciate you taking your time to review these patches. I 
will submit a V3.

>
> I guess code duplication is tolerable, because the format of
> s->identify_data is unlikely to change.  Comments linking the copies
> together wouldn't hurt, though.
>
> If we don't want the duplication, we need to factor the length code out
> of the identify functions, so we can use it in both places.
>

The length and complexity didn't feel like it needed to be factored out 
into two new functions, and I liked the idea of keeping the writes to 
the buffer sequential inside the initialization functions, because it 
made it easier for me to read along with the spec that way. Factoring it 
out seemed more of a fruitless hassle than anything.

Thanks,
--John

  reply	other threads:[~2014-08-14 16:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-13 17:21 [Qemu-devel] [PATCH v2] ide: Add resize callback to ide/core John Snow
2014-08-14  7:12 ` Markus Armbruster
2014-08-14 16:06   ` John Snow [this message]
2014-08-14 20:15     ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53ECDE81.7070401@redhat.com \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).