From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web09.23755.1605871080029233300 for ; Fri, 20 Nov 2020 03:18:00 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=N20j9Qf/; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605871079; 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=3CmySoHe+Fuyrh3PPaBhG2wCsSvBW9g1gCcNtyAi/0w=; b=N20j9Qf/xxwX8wwC+QngjZ29y0drkSAWrGjM4rdIoG9brqfUfepie/0LvPQA35RsFC2KX4 gg/S/v6yluQw0/sCb6v/1sdUGRHBXJCw/T+uGOfEM8PKm6/SA1ZoGZbTy0A66f3PrlEUDP dZxsneX+Df2wWq0qDIyGDWRCu5pWt54= 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-321-wOZUI6ggPxuteIpXUtdS9g-1; Fri, 20 Nov 2020 06:17:55 -0500 X-MC-Unique: wOZUI6ggPxuteIpXUtdS9g-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 95F7D94F11; Fri, 20 Nov 2020 11:17:47 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-10.ams2.redhat.com [10.36.115.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id EE0835C22A; Fri, 20 Nov 2020 11:17:42 +0000 (UTC) Subject: =?UTF-8?B?UmU6IOWbnuWkjTogW2VkazItZGV2ZWxdIEEgcHJvcG9zYWwgdG8gcmVkdWNlIGluY29tcGF0aWJsZSBjYXNl?= To: Ard Biesheuvel , gaoliming , devel@edk2.groups.io, jiewen.yao@intel.com, "'Liu, Zhiguang'" , michael.kubacki@outlook.com, awarkentin@vmware.com, debtech@gmail.com, "'Feng, Bob C'" , "'Tian, Hot'" Cc: 'Bret Barkelew' , "'Bi, Dandan'" , 'Chao Zhang' , "'Wang, Jian J'" , "'Wu, Hao A'" , 'Liming Gao' , "'Justen, Jordan L'" , 'Andrew Fish' , "'Ni, Ray'" , 'Bret Barkelew' , "'Kinney, Michael D'" References: <018a01d6bf0e$9a499810$cedcc830$@byosoft.com.cn> From: "Laszlo Ersek" Message-ID: <23ec860c-68cb-608e-d3b6-29c9513a30df@redhat.com> Date: Fri, 20 Nov 2020 12:17:41 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 11/20/20 10:02, Ard Biesheuvel wrote: > On 11/20/20 8:27 AM, gaoliming wrote: >> Zhiguang: >>    This proposal can reduce the potential library class dependency. >> Each package has its xxxPkgLib.dsc.inc file that includes the library >> instances from this package. >>    Platform DSC can include the required package lib.dsc.inc file for >> the library instances. Can you work out the code changes to >> demonstrate this idea? >> > > +1 for this idea. This would allow us to remove a *lot* of boilerplate > in the .DSC files, and focus on the libraries that actually matter for > the platform at hand. I feel like I'm in *cautious* agreement with this idea. In particular, I'd *only* like those lib class -> lib instance resolutions to be extracted, to DSC include files, that *cannot* involve platform choice. To put it differently, single-instance lib classes. ("Single-instance" can be interpreted per module type / per architecture of course -- so if a lib class has exactly 1 instance for PEIMs and exactly 1 (different) instance for DXE_DRIVERs, then those resolutions qualify for extraction.) If a library class genuinely has multiple instances in core edk2, then extracting a "default" resolution would be *wrong*, in my opinion. Every platform needs to make the choice explicitly, in such cases. This applies even if a lib class only has two instances, a functional one, and a Null one. The functional one should not be assumed default. Example: extracting the UefiLib resolution is valid. Extracting a SerialPortLib class resolution is invalid. Basically, I'd like to avoid *overrides*. Overrides are terribly hard to reason about. ... If someone wants to work on this, they'll have to implement this with *super small* patches, where every patch extracts resolutions for just one lib class. I would reject any patch that required me to review the extraction of two or more lib classes, from an OVMF or ArmVirt DSC file, at the same time. There is big potential in this proposal for making platform DSC files *permanently* more difficult to understand & analyze. I don't immediately see this proposal as a good solution for avoiding the current kind of platform DSC breakage. Platform CI would be much better, in my opinion. The proposal does seem workable, but the implementation needs to be surgical, IMO. OK, I'll get off my soap box now. Thanks Laszlo