From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web11.2075.1585730222590122261 for ; Wed, 01 Apr 2020 01:37:02 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Qp3+sikh; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585730221; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SGsDR/XqYs6WdvJjIz4RBSos3vcTKkYocSvyRb3TmzM=; b=Qp3+sikhgnyMJGbirsYedgg9CFasg8ueotmO9E+5jYzA2409rzMepk8eKjhMnuunuVSErE 57IfMqprVdNt7KyNMcY2LWguAhn2/AwlphivJkYbQt5tZeWAeJ0ZVbq57onCgigUVZZDwb mkihecvxDwGCT1KWQ7RvfnkLXLXDnEk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-159-V4E723wkNwWVrGgiOaLdvA-1; Wed, 01 Apr 2020 04:37:00 -0400 X-MC-Unique: V4E723wkNwWVrGgiOaLdvA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2497718A6EC3; Wed, 1 Apr 2020 08:36:59 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-94.ams2.redhat.com [10.36.114.94]) by smtp.corp.redhat.com (Postfix) with ESMTP id 26B925C1C5; Wed, 1 Apr 2020 08:36:57 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] OvmfPkg/PvScsiDxe: Fix VS2019 build error because of implicit cast To: Liran Alon , devel@edk2.groups.io, sean.brogan@microsoft.com References: <20200331110452.51992-1-liran.alon@oracle.com> <22866.1585670000047029434@groups.io> <4b90b41a-2cf1-8b6e-6619-1c652820265e@redhat.com> <5221e324-9f86-24b4-56a0-301a948151f8@oracle.com> <30a57406-0c09-043f-6b19-7e6e94afcb44@oracle.com> From: "Laszlo Ersek" Cc: Ard Biesheuvel Message-ID: <56339bff-ae66-2902-eb7b-3426a6b2cb7a@redhat.com> Date: Wed, 1 Apr 2020 10:36:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <30a57406-0c09-043f-6b19-7e6e94afcb44@oracle.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 04/01/20 00:17, Liran Alon wrote: > I would also mention that there are some bizzare code in EDK2 that > defines it's own ASSERT() macro that just does CpuDeadLoop(). E.g. > ArmVirtPkg/Library/ArmVirtDxeHobLib/HobLib.c This is a very special case. Please see the justification in commit ad90df8ac018 ("ArmPlatformPkg/ArmVirtualizationPkg: Add private HobLib implementation for DXE phase", 2014-09-18). The stock HobLib instance depends on DebugLib, for using the normal ASSERT() macro. Furthermore, the stock serial-based DebugLib instance depends on SerialPortLib, for printing messages. That produces a HobLib -> DebugLib -> SerialPortLib dependency chain. But, in case of this particular platform, our SerialPortLib instance depends on HobLib, for retrieving the particulars of the serial port. This creates a dependency cycle: HobLib -> DebugLib -> SerialPortLib -> HobLib which makes the platform un-buildable. We had to break the dependency cycle somewhere, and the best (or maybe only -- I don't recall exactly anymore) link to break was the HobLib -> DebugLib dependency. We introduced our own HobLib instance, which (IIRC) was almost identical to the stock one, except that its (only) DebugLib dependency, namely the ASSERT(), was reimplemented with a plain CpuDeadLoop(). And so the dependency chain ended up as: DebugLib -> SerialPortLib -> HobLib Not circular any more. > and OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c) Very similar same case; here we even have a comment: // // We can't use DebugLib due to a constructor dependency cycle between DebugLib // and ourselves. // The BaseDebugLibSerialPort instance depends on SerialPortLib, so a SerialPortLib instance cannot "depend back" on DebugLib, in combination with BaseDebugLibSerialPort. Thanks, Laszlo