From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2650D211E7444 for ; Tue, 2 Apr 2019 05:56:43 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 029BB309264C; Tue, 2 Apr 2019 12:56:43 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-182.rdu2.redhat.com [10.10.120.182]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4BE8E6842B; Tue, 2 Apr 2019 12:56:38 +0000 (UTC) To: Ryszard Knop , Leif Lindholm Cc: Michael Kinney , "edk2-devel@lists.01.org" , "Gao, Liming" , "Bi, Dandan" , Stephano Cetola , "Carsey, Jaben" References: <3C0D5C461C9E904E8F62152F6274C0BB40BB5D6F@SHSMSX104.ccr.corp.intel.com> <9492a5a0-58fc-4e49-4645-0593aa758660@redhat.com> <20190402091230.zmwcrwb6s55ontm5@bivouac.eciton.net> <3c20917e-e091-354e-5c2d-09dc2a49ea0f@redhat.com> From: Laszlo Ersek Message-ID: <812b93ca-d1a6-73cc-1f76-a27a9425673d@redhat.com> Date: Tue, 2 Apr 2019 14:56:37 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Tue, 02 Apr 2019 12:56:43 +0000 (UTC) Subject: Re: [RFC] Plan to delete ShellBinPkg from edk2/master X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 12:56:45 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 04/02/19 13:50, Ryszard Knop wrote: > On Tue, 2019-04-02 at 13:45 +0200, Laszlo Ersek wrote: >> On 04/02/19 13:29, Ryszard Knop wrote: >>> On Tue, 2019-04-02 at 10:12 +0100, Leif Lindholm wrote: >>>> Hi Laszlo, >>>> >>>> On Tue, Apr 02, 2019 at 10:49:16AM +0200, Laszlo Ersek wrote: >>>>> On 04/02/19 07:38, Bi, Dandan wrote: >>>>>> Hi All, >>>>>> >>>>>> ShellBinPkg is the remaining binary package in Edk2 repo. We >>>>>> plan >>>>>> to delete ShellBinPkg from edk2/master, and keep source >>>>>> ShellPkg >>>>>> only in edk2 repo. >>>>>> Before the deletion, I will update the existing consumers in >>>>>> Edk2 >>>>>> and Edk2Platforms to use ShellPkg directly. >>>>>> >>>>>> If you have any concern please raise here before mid-April . >>>>>> If >>>>>> there is no concern, I will create patches for this task >>>>>> after >>>>>> mid-April. >>>>>> >>>>>> Bugzilla for this task: >>>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=1675 >>>>> >>>>> (adding a few CC's) >>>>> >>>>> I think we should not remove ShellBinPkg without a replacement >>>>> *somehwere*. >>>>> >>>>> A shell binary that is built from a validated edk2 tree, with a >>>>> set >>>>> of >>>>> library resolutions and PCD settings that are known to keep >>>>> platform >>>>> dependencies *out* of the shell binary, is extremely useful. >>>> >>>> Agreed. However, I am not sure that accurately describes what we >>>> have >>>> today. >>>> >>>>> IIRC, Andrew suggested earlier that we should treat the shell >>>>> even >>>>> as an >>>>> "OS", with better compatibility standards than we currently >>>>> maintain. >>>>> >>>>> I think we should only remove ShellBinPkg if we permanently >>>>> offer a >>>>> separate download location instead, and we rebuild the shell >>>>> binary >>>>> from >>>>> "ShellPkg/ShellPkg.dsc" at every stable tag. >>>> >>>> I think this sounds like an exellent improvement. When I saw the >>>> patch, I did immediately think maybe I should start including >>>> them in >>>> my Linaro releases. But if we could automate a build of binaries >>>> for >>>> all supported architectures, and have a place to publish them, >>>> that >>>> would be much better. >>> >>> One place to put them might be next to the stable releases on >>> GitHub. >>> Sources are automatically packaged there, binaries can also be >>> uploaded, also automatically via CI. (Maybe it could also be used >>> to >>> keep stable OVMF images? Would be nice for quick testing for people >>> not >>> involved in UEFI development and not having these binaries >>> available in >>> their OS repos, or having issues with 3rd party builds.) >> >> OVMF and ArmVirtQemu binaries are being bundled with upstream QEMU. >> The >> series should be merged into QEMU 4.1. > > Right, but for people stuck on older QEMU versions it'd be useful to > find everything conveniently in one place when googling "OVMF". And > there are quite a few of these versions in the wild: > https://repology.org/project/qemu/versions This doesn't seem to be a problem with the UEFI shell, but 'everything conveniently in one place when googling "OVMF"' seems like a ship that has sailed. To exaggerate a bit, when you google "Linux" or "QEMU", you don't find everything in one place either. :) For bleeding edge builds, people can (and do) already consume . The point of bundling binaries, built from the latest edk2-stableYYYYMM tag, with QEMU, is two-fold: (a) following the tradition of bundling SeaBIOS, iPXE, and other firmware(-level) binaries with QEMU, (b) allowing QEMU's own "make check" to run UEFI helper apps in guests, without external dependencies (both the platform firmware binaries and the UEFI app(s) are to be tracked in the QEMU git tree). NB purpose (a) is not universally accepted for QEMU either; there have been ideas to move all of those firmware thingies out of QEMU. I'm neutral on that longer-term question; for now, adding ArmVirtQemu and OVMF binaries to the QEMU tree sticks with the tradition and improves the availability of those firmware binaries. That said, I'm not against offering OVMF builds via some kind of TianoCore-owned CI. We should just be aware that adding more download locations and calling them "official" will likely not eliminate any builds we consider "unofficial". I'm undecided whether a new download location will mitigate the confusion, or contribute to it. Thanks, Laszlo >> The plan is to refresh the firmware binaries for each edk2 stable >> tag. >> >> (It's also possible that users could benefit from synching QEMU and >> edk2 >> releases to an extent, similarly to how SeaBIOS and QEMU tend to be >> in >> sync. (IIRC SeaBIOS tends to cut a new release shortly before QEMU, >> so >> that QEMU can pick up the most recent release while it's fresh.) >> Anyway >> this sub-topic is for the future.) >> >> Thanks >> Laszlo >