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 6947221A07A80 for ; Mon, 3 Dec 2018 09:10:03 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E5E428666F; Mon, 3 Dec 2018 17:10:02 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-61.rdu2.redhat.com [10.10.120.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id AAD705D772; Mon, 3 Dec 2018 17:10:01 +0000 (UTC) To: Leif Lindholm Cc: Andrew Fish , Michael Kinney , "edk2-devel@lists.01.org" References: <20181129224102.ab43kwgrkk6xz2bl@bivouac.eciton.net> <129a947f.308c.167624a3bd2.Coremail.sssky307@163.com> <179708E3-F8AD-41B4-90B5-ECFD94924986@apple.com> <0cecc14d-f268-6fcb-d185-e0bddecd4f1e@redhat.com> <20181203150756.up6iaez5sl25f7fu@bivouac.eciton.net> From: Laszlo Ersek Message-ID: <95e6cab4-0668-4e0e-75a5-15fb876e1fe5@redhat.com> Date: Mon, 3 Dec 2018 18:10:00 +0100 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: <20181203150756.up6iaez5sl25f7fu@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 03 Dec 2018 17:10:03 +0000 (UTC) Subject: Re: [RFC] Proposal to add edk2-apps repository 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: Mon, 03 Dec 2018 17:10:03 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 12/03/18 16:07, Leif Lindholm wrote: > On Mon, Dec 03, 2018 at 03:11:33PM +0100, Laszlo Ersek wrote: >> On 11/30/18 07:03, Andrew Fish wrote: >>> Mike, >>> >>> As Krishna points out there are flavors of Apps. Do we want to have >>> different packages for different flavor of apps, or different dirs in >>> a more generic App package? Maybe we should define classes of UEFI >>> Applications in the README.md and give them a place to live. >> >> In my opinion, this is absolutely the first step that should be done. > > Yes please. > >> Personally, I've just learned, from this thread, that there are *three* >> (not two) UEFI application entry point types that edk2 supports. >> >> * I've always known about main() -- libc app --, and ShellAppMain() -- >> shell app. I've always known these because I read about them in >> "AppPkg/ReadMe.txt" and "StdLib/ReadMe.txt" years ago. In particular, >> compare the description of "Hello" and "Main". >> >> * And now MdeModulePkg/Application has been mentioned, in this thread, >> where I see UefiMain() as the entry point. > > Well, these are defined by the application .inf though, so "UefiMain" > is just a common name picked. MdeModulePkg/Application also has > applications with entry points called 'BootManagerMenuEntry', > 'SmiHandlerProfileInfoEntrypoint' and 'InitializeUserInterface'. (The > latter being UiApp.) Right, I guess I should have referred to the "UefiApplicationEntryPoint" lib class instead. (I did so below.) > >> I don't recall reading about UefiMain() or UefiApplicationEntryPoint on >> this list. On the other hand, I remember several discussions where >> people asked if they could write an application and invoke it from >> SysPrep#### or similar, and the answer has always been, "oh sorry you >> can't do that, because the lowest level you can go is ShellAppMain(), >> and that won't work from SysPrep####". > > Huh? Who claimed that? Where? Sorry, don't have any specifics, just a lingering (but strong) memory. > (I suspect the meaning of "Application" has taken on some > overly-specific meaning for someone if they have claimed such - going > back to how having a proper definition is clearly quite important.) > > Of course they can. Any EDK2 image itself contains a bunch of .efi > executables - and there is nothing preventing you from invoking those > from the shell. The dependency was the other way around. UEFI_APPLICATION modules built with ShellCEntryLib would depend on the shell to function, and the shell was not available when the boot manager launched the apps via SysPrep####. This argument actually makes sense to me; I'm not positing that ShellCEntryLib apps "should" work in the above situation. The problem is that the functional alternative (UefiApplicationEntryPoint) has been super difficult to learn about (from my personal POV anyway). > And don't forget most platforms ship without a built-in Shell, correct > so there would be no way of running ... anything ... if that was true. It would be more precise to put this as, there would be no way of running any *application*, built with *edk2*, directly from the *boot manager* and that had been my exact mental image until I read this thread. > Also, it's pretty much the whole point of gnu-efi (combined with doing > it directly in a normal POSIX environment). I agree 100%, and I didn't forget about shim, grub, or gnu-efi -- please note the emphasis on "edk2" in my above reformulation. Thanks Laszlo