From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00, CHARSET_FARAWAY_HEADER,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A00ACC2D0A3 for ; Thu, 12 Nov 2020 07:52:19 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 589FD221FC for ; Thu, 12 Nov 2020 07:52:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 589FD221FC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zhaoxin.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:40658 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kd7Oz-0000Yz-AD for qemu-devel@archiver.kernel.org; Thu, 12 Nov 2020 02:52:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58964) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kd7Nr-00087C-LP for qemu-devel@nongnu.org; Thu, 12 Nov 2020 02:51:07 -0500 Received: from zxshcas1.zhaoxin.com ([203.148.12.81]:32249) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kd7Nm-0008Tl-1U for qemu-devel@nongnu.org; Thu, 12 Nov 2020 02:51:07 -0500 Received: from zxbjmbx2.zhaoxin.com (10.29.252.164) by ZXSHCAS1.zhaoxin.com (10.28.252.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 12 Nov 2020 15:29:25 +0800 Received: from zxbjmbx1.zhaoxin.com (10.29.252.163) by zxbjmbx2.zhaoxin.com (10.29.252.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 12 Nov 2020 15:29:25 +0800 Received: from zxbjmbx1.zhaoxin.com ([fe80::290a:f538:51e7:1416]) by zxbjmbx1.zhaoxin.com ([fe80::290a:f538:51e7:1416%16]) with mapi id 15.01.1979.003; Thu, 12 Nov 2020 15:29:24 +0800 From: RockCui-oc To: John Snow , Max Reitz , "qemu-devel@nongnu.org" Subject: =?gb2312?B?tPC4tDogW1BBVENIXSBpZGU6ZG8gbm90aGluZyBmb3IgaWRlbnRpZnkgY21k?= =?gb2312?Q?_if_no_any_device_attached?= Thread-Topic: [PATCH] ide:do nothing for identify cmd if no any device attached Thread-Index: AQHWdEfWn1VcMPOnkU+PO9h+3wgKR6lVN70AgAEW7ACALil7gIBAKUvr Date: Thu, 12 Nov 2020 07:29:24 +0000 Message-ID: <306775bc63c3417fba11fd93a53e3d32@zhaoxin.com> References: <20200817033803.14014-1-RockCui-oc@zhaoxin.com> <8dbcc856-879a-af83-1a76-a2a875da3699@redhat.com> <0347935f-5235-3c61-07cc-fb4435ec45d1@redhat.com>, <3fc6d5fa-c305-606a-5e8f-23e90eadd588@redhat.com> In-Reply-To: <3fc6d5fa-c305-606a-5e8f-23e90eadd588@redhat.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.29.8.17] Content-Type: multipart/alternative; boundary="_000_306775bc63c3417fba11fd93a53e3d32zhaoxincom_" MIME-Version: 1.0 Received-SPF: pass client-ip=203.148.12.81; envelope-from=RockCui-oc@zhaoxin.com; helo=ZXSHCAS1.zhaoxin.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/12 02:29:27 X-ACL-Warn: Detected OS = Windows 7 or 8 [fuzzy] X-Spam_score_int: 38 X-Spam_score: 3.8 X-Spam_bar: +++ X-Spam_report: (3.8 / 5.0 requ) BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , "Cobe Chen\(BJ-RD\)" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --_000_306775bc63c3417fba11fd93a53e3d32zhaoxincom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxso6wNCg0KDQpBbnkgc3VnZ2VzdGlvbnMgZm9yIHRoaXMgcGF0Y2ijvw0KDQpSb2NrDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEpvaG4gU25vdyA8anNu b3dAcmVkaGF0LmNvbT4NCreiy83KsbzkOiAyMDIwxOoxMNTCM8jVIDM6MzcNCsrVvP7IyzogTWF4 IFJlaXR6OyBSb2NrQ3VpLW9jOyBxZW11LWRldmVsQG5vbmdudS5vcmcNCrOty806IFBldGVyIE1h eWRlbGw7IENvYmUgQ2hlbihCSi1SRCkNCtb3zOI6IFJlOiBbUEFUQ0hdIGlkZTpkbyBub3RoaW5n IGZvciBpZGVudGlmeSBjbWQgaWYgbm8gYW55IGRldmljZSBhdHRhY2hlZA0KDQpPbiA5LzMvMjAg Njo0MCBBTSwgTWF4IFJlaXR6IHdyb3RlOg0KPiBPbiAwMi4wOS4yMCAyMDowMiwgSm9obiBTbm93 IHdyb3RlOg0KPj4gKENDIE1heCBmb3IgYmxvY2sgYmFja2VuZCBtb2RlbCBjb25mdXNpb24sIHNl ZSBiZWxvdykNCj4+DQo+PiBPbiA4LzE2LzIwIDExOjM4IFBNLCB6aGFveGluXFJvY2tDdWlvYyB3 cm90ZToNCj4+PiBUaGlzIHBhdGNoIGlzIGZvciBhdm9pZGluZyB3aW43IElERSBkcml2ZXIgcG9s bGluZyAweDFmNyB3aGVuDQo+Pj4gbm8gYW55IGRldmljZSBhdHRhY2hlZC4gRHVyaW5nIFdpbjcg Vk0gYm9vdCBwcm9jZWR1cmUsIGlmIHVzZSB2aXJ0aW8gZm9yDQo+Pj4gZGlzayBhbmQgdGhlcmUg aXMgbm8gYW55IGRldmljZSBiZSBhdHRhY2hlZCBvbiBoZGEgJiBoZGIsIHRoZSB3aW43IElERQ0K Pj4+IGRyaXZlcg0KPj4+IHdvdWxkIHBvbGwgMHgxZjcgZm9yIGEgd2hpbGUuIFRoaXMgYWN0aW9u IG1heSBiZSBzdG9wIHdpbmRvd3MgTE9HTw0KPj4+IGF0b21pYyBmb3INCj4+PiBhIHdoaWxlIHRv byBvbiBhIHBvb3IgcGVyZm9ybWFuY2UgQ1BVLg0KPj4+DQo+Pg0KPj4gQSBmZXcgcXVlc3Rpb25z Og0KPj4NCj4+ICgxKSBIb3cgc2xvdyBpcyB0aGUgcHJvYmluZz8NCj4+DQo+PiAoMikgSWYgdGhl cmUgYXJlIG5vIGRldmljZXMgYXR0YWNoZWQsIHdoeSBkb24ndCB5b3UgcmVtb3ZlIHRoZSBJREUN Cj4+IGNvbnRyb2xsZXIgc28gdGhhdCBXaW5kb3dzIGRvZXNuJ3QgaGF2ZSB0byBwcm9iZSBpdD8N Cj4+DQo+Pj4gU2lnbmVkLW9mZi1ieTogemhhb3hpblxSb2NrQ3Vpb2MgPFJvY2tDdWktb2NAemhh b3hpbi5jb20+DQo+Pj4gLS0tDQo+Pj4gICAgaHcvaWRlL2NvcmUuYyB8IDUgKysrLS0NCj4+PiAg ICAxIGZpbGUgY2hhbmdlZCwgMyBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQ0KPj4+DQo+ Pj4gZGlmZiAtLWdpdCBhL2h3L2lkZS9jb3JlLmMgYi9ody9pZGUvY29yZS5jDQo+Pj4gaW5kZXgg ZDk5N2E3OGU0Ny4uMjZkODZmNGI0MCAxMDA2NDQNCj4+PiAtLS0gYS9ody9pZGUvY29yZS5jDQo+ Pj4gKysrIGIvaHcvaWRlL2NvcmUuYw0KPj4+IEBAIC0yMDczLDggKzIwNzMsOSBAQCB2b2lkIGlk ZV9leGVjX2NtZChJREVCdXMgKmJ1cywgdWludDMyX3QgdmFsKQ0KPj4+ICAgICAgICBzID0gaWRl YnVzX2FjdGl2ZV9pZihidXMpOw0KPj4+ICAgICAgICB0cmFjZV9pZGVfZXhlY19jbWQoYnVzLCBz LCB2YWwpOw0KPj4+ICAgIC0gICAgLyogaWdub3JlIGNvbW1hbmRzIHRvIG5vbiBleGlzdGVudCBz bGF2ZSAqLw0KPj4+IC0gICAgaWYgKHMgIT0gYnVzLT5pZnMgJiYgIXMtPmJsaykgew0KPg0KPiAo V2FzIHRoZSBmaXJzdCBvbmUgYmFzaWNhbGx5IG1lYW50IHRvIGJlIKGwcyAhPSAmYnVzLT5pZnNb MF2hsSwgaS5lLiB0bw0KPiBjaGVjayB0aGF0IHRoaXMgZG9lc26hr3QgZ28gdG8gdGhlIG1hXlcg cHJpbWFyeT8gIE5vdCB0b28gb2J2aW91cy4pDQo+DQoNClllYWgsIEkgdGhpbmsgaXQgd2FzIG1l YW50IHRvIHNheToNCg0KaWYgKHMgPT0gYnVzLT5pZnNbMV0gJiYgIXMtPmJsaykNCg0KKEJ1dCBJ IGRvbid0IGtub3cgd2h5IGl0IHdhcyBpbXBvcnRhbnQgdG8gZ3VhcmQgZGV2aWNlMSBzcGVjaWZp Y2FsbHkuDQpLbm93bGVkZ2UgbG9zdCB0byB0aGUgc2FuZHMgb2YgdGltZS4pDQoNCkJ5IHRoZSB3 YXksIHRoZSBjb3JyZWN0IHRlcm1zIGFyZSAiZGV2aWNlMCIgYW5kICJkZXZpY2UxIiBhbmQgaGF2 ZSBiZWVuDQpzaW5jZSBhdCBsZWFzdCBBVEEyLiBJIGJlbGlldmUgQVRBMSB1c2VkIHRoZSB0ZXJt cyAiZGlzazAiIGFuZCAiZGlzazEiLg0KIlByaW1hcnkiIGFuZCAiU2Vjb25kYXJ5IiBhcmUgdXNl ZCB0byByZWZlciB0byB0aGUgY29udHJvbGxlcnMsIG5vdCB0aGUNCmRldmljZXMuDQoNCi0gUHJp bWFyeQ0KICAgLSBkZXZpY2UwDQogICAtIGRldmljZTENCi0gU2Vjb25kYXJ5DQogICAtIGRldmlj ZTANCiAgIC0gZGV2aWNlMQ0KDQpUaGFua3MgZm9yIGNvbWluZyB0byBteSBURUQgdGFsayENCg0K Pj4+ICsgICAgLyogaWdub3JlIGNvbW1hbmRzIGlmIG5vIGFueSBkZXZpY2UgZXhpc3Qgb3Igbm9u IGV4aXN0ZW50IHNsYXZlICovDQo+Pj4gKyAgICBpZiAoKCFidXMtPmlmc1swXS5ibGsgJiYgIWJ1 cy0+aWZzWzFdLmJsaykgfHwNCj4+PiArICAgICAgICAocyAhPSBidXMtPmlmcyAmJiAhcy0+Ymxr KSkgew0KPg0KPiAoTWF5YmUgdGhpcyBjb3VsZCBiZSBpbXByb3ZlZCBoZXJlKQ0KPg0KPj4+ICAg ICAgICAgICAgcmV0dXJuOw0KPj4+ICAgICAgICB9DQo+Pj4NCj4+DQo+PiBJIHRoaW5rIGl0J3Mg dGhlIGNhc2UgdGhhdCBFbXB0eSBDRC1ST00gZHJpdmVzIHdpbGwgaGF2ZSBhbiBhbm9ueW1vdXMN Cj4+IGJsb2NrIGJhY2tlbmQgcmVwcmVzZW50aW5nIHRoZSBlbXB0eSBkcml2ZSwNCj4NCj4gKEFz IGZhciBhcyBJIHJlbWVtYmVyLCkgeWVzLg0KPg0KPiAoaWRlX2Rldl9pbml0Zm4oKSBlbnN1cmVz IGFsbCBDRCBkcml2ZXMgaGF2ZSBvbmUsIGV2ZW4gaWYgaXShr3MgZW1wdHkuKQ0KPg0KDQooVGhh bmtzKQ0KDQo+PiBzbyBJIHN1cHBvc2UgdGhpcyBpcyBtYXliZQ0KPj4gZmluZT8NCj4+DQo+PiBJ IHN1cHBvc2UgdGhlIGlkZWEgaXMgdGhhdCB3aXRoIG5vIGRyaXZlcyBvbiB0aGUgYnVzIHRoYXQg aXQncyBmaW5lIHRvDQo+PiBpZ25vcmUgdGhlIHJlZ2lzdGVyIHdyaXRlcywgYXMgdGhlcmUgYXJl IG5vIGRldmljZXMgdG8gcmVjb3JkIHRob3NlIHdyaXRlcy4NCj4+DQo+PiAoQnV0IHRoZW4sIHdo eSBkaWQgd2UgZXZlciBvbmx5IGNoZWNrIGRldmljZTE/IC4uLikNCj4+DQo+PiBNYXliZSBiZWZv cmUgdGhlIGJsb2NrLWJhY2tlbmQgc3BsaXQgd2UgdXNlZCB0byBoYXZlIHRvIGNoZWNrIHRvIHNl ZSBpZg0KPj4gd2UgaGFkIGF0dGFjaGVkIG1lZGlhIG9yIG5vdCwgYnV0IEkgdGhpbmsgbm93YWRh eXMgd2Ugc2hvdWxkIGFsd2F5cyBoYXZlDQo+PiBhIGJsayBwb2ludGVyIGlmIHdlIGhhdmUgYSBk ZXZpY2UgbW9kZWwgaW50ZW5kZWQgdG8gYmUgb3BlcmF0aW5nIGF0IHRoaXMNCj4+IGFkZHJlc3Mu DQo+DQo+IFRoZSBjaGVjayBpbiBpZGVfZGV2X2luaXRmbigpIGxvb2tzIHRoYXQgd2F5IHRvIG1l Lg0KPg0KPj4gU28gSSBndWVzcyBpdCBjYW4gYmUgc2ltcGxpZmllZCAuLi4/DQo+Pg0KPj4gaWYg KCFzLT5ibGspIHsNCj4+ICAgICAgcmV0dXJuOw0KPj4gfQ0KPg0KPiBQcm9iYWJseS4gIEFsdGhv dWdoIHRoZXJloa9zIGEgZGlmZmVyZW5jZSwgb2YgY291cnNlLCBuYW1lbHkgaWYgeW91IGhhdmUN Cj4gb25seSBhIHNlY29uZGFyeSBkZXZpY2UgYW5kIHRyeSB0byBhY2Nlc3MgdGhlIHByaW1hcnks IHRoaXMgc2ltcGxpZmllZA0KPiB2ZXJzaW9uIHdpbGwgYmUgYSBuby1vcCwgd2hlcmVhcyB0aGUg bW9yZSBjb21wbGljYXRlZCB2ZXJzaW9uIGluIHRoaXMNCj4gcGF0Y2ggd291bGQgc3RpbGwgZ28g b24uICBJIGRvbqGvdCBrbm93IGhvdyByZWFsIGhhcmR3YXJlIHdvdWxkIGhhbmRsZQ0KPiB0aGF0 IGNhc2UuICBJcyBpdCBldmVuIHBvc3NpYmxlIHRvIGhhdmUganVzdCBhIHNlY29uZGFyeSB3aXRo IG5vIHByaW1hcnk/DQo+DQoNCkkgdGhpbmsgc28uIEZyb20gd2hhdCBJIHVuZGVyc3RhbmQsIHR3 byBkcml2ZXMgb24gYSBzaW5nbGUgY2hhbm5lbCBib3RoDQpyZWNlaXZlIGFsbCBvZiB0aGUgc2Ft ZSByZWdpc3RlciB1cGRhdGUgY29tbWFuZHMsIGluY2x1ZGluZyB0aGUgIlNFTEVDVCINCnJlZ2lz dGVyLCB3aGljaCBoYXMgYSBiaXQgZGV2b3RlZCB0byB3aGljaCBkcml2ZSB3ZSBoYXZlIHNlbGVj dGVkLg0KDQpXaGVuIHdlIHdyaXRlIHRvIHRoZSBDT01NQU5EIHJlZ2lzdGVyLCBvbmx5IHRoZSBz ZWxlY3RpdmUgZHJpdmUgc2hvdWxkDQphY3R1YWxseSByZXNwb25kIHRvIGl0Lg0KDQpzbyB3aGF0 IEkgZXhwZWN0IGhhcHBlbnMgb24gcmVhbCBtYWNoaW5lczoNCg0KLSBZb3Ugc2VsZWN0IGRldmlj ZTANCi0gWW91IHdyaXRlIHRvIGEgYnVuY2ggb2YgcmVnaXN0ZXJzDQotIFlvdSBpc3N1ZSBhIGNv bW1hbmQNCi0gTm9ib2R5IHJlc3BvbmRzLg0KDQotLWpzDQoNCg== --_000_306775bc63c3417fba11fd93a53e3d32zhaoxincom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all=A3=AC


Any suggestions for this patch=A3=BF


Rock

=B7=A2=BC=FE=C8=CB: John = Snow <jsnow@redhat.com>
=B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA10=D4=C23=C8=D5 3:37
=CA=D5=BC=FE=C8=CB: Max Reitz; RockCui-oc; qemu-devel@nongnu.org
=B3=AD=CB=CD: Peter Maydell; Cobe Chen(BJ-RD)
=D6=F7=CC=E2: Re: [PATCH] ide:do nothing for identify cmd if no any = device attached
 
On 9/3/20 6:40 AM, Max Reitz wrote:
> On 02.09.20 20:02, John Snow wrote:
>> (CC Max for block backend model confusion, see below)
>>
>> On 8/16/20 11:38 PM, zhaoxin\RockCuioc wrote:
>>> This patch is for avoiding win7 IDE driver polling 0x1f7 when<= br> >>> no any device attached. During Win7 VM boot procedure, if use = virtio for
>>> disk and there is no any device be attached on hda & hdb, = the win7 IDE
>>> driver
>>> would poll 0x1f7 for a while. This action may be stop windows = LOGO
>>> atomic for
>>> a while too on a poor performance CPU.
>>>
>>
>> A few questions:
>>
>> (1) How slow is the probing?
>>
>> (2) If there are no devices attached, why don't you remove the IDE=
>> controller so that Windows doesn't have to probe it?
>>
>>> Signed-off-by: zhaoxin\RockCuioc <RockCui-oc@zhaoxin.com>= ;
>>> ---
>>>    hw/ide/core.c | 5 +++--
>>>    1 file changed, 3 insertions(+), 2 deletions(= -)
>>>
>>> diff --git a/hw/ide/core.c b/hw/ide/core.c
>>> index d997a78e47..26d86f4b40 100644
>>> --- a/hw/ide/core.c
>>> +++ b/hw/ide/core.c
>>> @@ -2073,8 +2073,9 @@ void ide_exec_cmd(IDEBus *bus, uint3= 2_t val)
>>>        s =3D idebus_active_if(bu= s);
>>>        trace_ide_exec_cmd(bus, s= , val);
>>>    -    /* ignore commands to non exi= stent slave */
>>> -    if (s !=3D bus->ifs && !s->b= lk) {
>
> (Was the first one basically meant to be =A1=B0s !=3D &bus->ifs= [0]=A1=B1, i.e. to
> check that this doesn=A1=AFt go to the ma^W primary?  Not too obv= ious.)
>

Yeah, I think it was meant to say:

if (s =3D=3D bus->ifs[1] && !s->blk)

(But I don't know why it was important to guard device1 specifically.
Knowledge lost to the sands of time.)

By the way, the correct terms are "device0" and "device1&quo= t; and have been
since at least ATA2. I believe ATA1 used the terms "disk0" and &q= uot;disk1".
"Primary" and "Secondary" are used to refer to the cont= rollers, not the
devices.

- Primary
   - device0
   - device1
- Secondary
   - device0
   - device1

Thanks for coming to my TED talk!

>>> +    /* ignore commands if no any device ex= ist or non existent slave */
>>> +    if ((!bus->ifs[0].blk && !b= us->ifs[1].blk) ||
>>> +        (s !=3D bus-&g= t;ifs && !s->blk)) {
>
> (Maybe this could be improved here)
>
>>>            r= eturn;
>>>        }
>>>   
>>
>> I think it's the case that Empty CD-ROM drives will have an anonym= ous
>> block backend representing the empty drive,
>
> (As far as I remember,) yes.
>
> (ide_dev_initfn() ensures all CD drives have one, even if it=A1=AFs em= pty.)
>

(Thanks)

>> so I suppose this is maybe
>> fine?
>>
>> I suppose the idea is that with no drives on the bus that it's fin= e to
>> ignore the register writes, as there are no devices to record thos= e writes.
>>
>> (But then, why did we ever only check device1? ...)
>>
>> Maybe before the block-backend split we used to have to check to s= ee if
>> we had attached media or not, but I think nowadays we should alway= s have
>> a blk pointer if we have a device model intended to be operating a= t this
>> address.
>
> The check in ide_dev_initfn() looks that way to me.
>
>> So I guess it can be simplified ...?
>>
>> if (!s->blk) {
>>      return;
>> }
>
> Probably.  Although there=A1=AFs a difference, of course, namely = if you have
> only a secondary device and try to access the primary, this simplified=
> version will be a no-op, whereas the more complicated version in this<= br> > patch would still go on.  I don=A1=AFt know how real hardware wou= ld handle
> that case.  Is it even possible to have just a secondary with no = primary?
>

I think so. From what I understand, two drives on a single channel both receive all of the same register update commands, including the "SELEC= T"
register, which has a bit devoted to which drive we have selected.

When we write to the COMMAND register, only the selective drive should
actually respond to it.

so what I expect happens on real machines:

- You select device0
- You write to a bunch of registers
- You issue a command
- Nobody responds.

--js

--_000_306775bc63c3417fba11fd93a53e3d32zhaoxincom_--