From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web08.62820.1606754896171484984 for ; Mon, 30 Nov 2020 08:48:16 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=M8YP35mJ; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606754895; 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=tZHCHxibig/AFryGzRkBZaW0gmTQ8xBmUP8GY+HUcmM=; b=M8YP35mJQA4eoGskfPhgEud1hktFX5MbzqrUpqSQLv+ZYulQ12cUdTy+E4p8nDNk/JktLF MYDW7fxE7XfTTml6ZYZ/+6Yj5v4nqONc6Av3b6/74zg+ieTxjpiMrhWAtMeXBeFwWU+64a jyNk0vw9wU1sFa8JvQzaLHq58hwZXe4= 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-76-YAUrbpzqPkuPIAPbz4TL3w-1; Mon, 30 Nov 2020 11:48:10 -0500 X-MC-Unique: YAUrbpzqPkuPIAPbz4TL3w-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6436B107ACFA; Mon, 30 Nov 2020 16:48:07 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-120.ams2.redhat.com [10.36.112.120]) by smtp.corp.redhat.com (Postfix) with ESMTP id F0CE219C71; Mon, 30 Nov 2020 16:48:01 +0000 (UTC) Subject: =?UTF-8?B?UmU6IOWbnuWkjTogW2VkazItZGV2ZWxdIEEgcHJvcG9zYWwgdG8gcmVkdWNlIGluY29tcGF0aWJsZSBjYXNl?= To: "Liu, Zhiguang" , Ard Biesheuvel , gaoliming , "devel@edk2.groups.io" , "Yao, Jiewen" , "Feng, Bob C" , "Tian, Hot" , 'Bret Barkelew' Cc: "Bi, Dandan" , 'Chao Zhang' , "Wang, Jian J" , "Wu, Hao A" , 'Liming Gao' , "Justen, Jordan L" , 'Andrew Fish' , "Ni, Ray" , 'Bret Barkelew' , "Kinney, Michael D" , "debtech@gmail.com" , "awarkentin@vmware.com" , "michael.kubacki@outlook.com" References: <018a01d6bf0e$9a499810$cedcc830$@byosoft.com.cn> <23ec860c-68cb-608e-d3b6-29c9513a30df@redhat.com> From: "Laszlo Ersek" Message-ID: <9ac23b89-d905-ee15-be93-1dba337f1cef@redhat.com> Date: Mon, 30 Nov 2020 17:48:00 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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: 7bit On 11/29/20 13:31, Liu, Zhiguang wrote: > Hi all, > > > > I write a python script to do the work, including classify all the library instance, generating the including lib file. > > In the attachment file, the first sheet includes all "Single-instance", which means in edk2 and edk2-platforms repo, only one inf files has the specified library name. > The second sheet includes all "Multi-Single-instance", which means in edk2 and edk2-platforms repo, for a specified module type and arch, this inf is a "Single-instance". > > I think the library instance in the first two sheet can be extracted as a XXXLibs.dsc.inc > > > > Here is the draft code > > https://github.com/LiuZhiguang001/edk2/commits/extract_lib > > > > Here is the source code of this tool > > https://github.com/LiuZhiguang001/MyTool/tree/extract_lib > > > > Please review the excel and the draft code. > > If no comments, I will send out a formal patch next week. I've briefly checked the first two sheets of the spreadsheet, regarding OvmfPkg and ArmVirtPkg. Those parts look sensible to me. Regarding the code, namely the patch "OvmfPkg:Add OvmfLibs.dsc.inc" -- I really dislike even briefly checking patches that are not on the list, as we then get into a back-and-forth about them, and then it would just make more sense to post the patch to the list, and discuss it there. But, in this case, I did take a quick look. I don't like the approach. First, the new DSC include file is apparently not put to use in the OvmfPkg DSC files at all. IIUC, the DSC include files should not only come as additions, but they should replace existent lib class resolutions where they can. Second (and I stated this before), given a new DSC include file, I'd like to see each affected library class resolution to be migrated *one by one* from the DSC file(s) to the new DSC include file. If you have 10 affected lib classes for OVMF, that will take 10 patches for OVMF. I will have to validate every lib class resolution movement one by one anyway, in isolation (I won't just blindly trust the python tool that generates these new files, sorry), and for that kind of review, I need the patches to be broken-out accordingly. If this creates too many patches in the series (for example the first sheet in the spreadsheet has 144 rows), then I suggest writing a separate series for each package, or something similar. Thanks Laszlo