From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::129; helo=mail-it1-x129.google.com; envelope-from=df7729@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 58BB4211963F0 for ; Mon, 10 Dec 2018 23:26:53 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id z7so2128988iti.0 for ; Mon, 10 Dec 2018 23:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cDScaNtGhtYYqL7d0/rikQIiFriK0knubeBRJLlxSvU=; b=EuyLsG6+Z9QB8OuWMMfxTal894pq/iMW3Azc/lRQ9xmJ+RnwUcfiw/SFqNq7j/MqHL /VNMmQHnrL06iq5MhDizlpBceh0AmvEcY3ZnFwMrlfahOARcEAQ6kKiCmHYH8JLbBKHm bjVV2g65ofVPEwT97Ki0qNhZ3nb5d9bJt02Q4apMShPfG2eRdIq9wXwqQvI4eCng7DLm j41hMSUPfstH/KYuiGOqn5KeU7tEOXyOUKum8NlhhBqA6KDerH0lpFS1k+XW84creByt LtpVNC80pjlHFCPswuWJFtpXv3AHughWTFXWganyMFlahPmSstNfcUQLQf68DaM2PKVw B6/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cDScaNtGhtYYqL7d0/rikQIiFriK0knubeBRJLlxSvU=; b=SV3vd6hNN9ZAzPY6e42yy9emO1gJyOK2TeRSzL6PBI8+vUM0k6Xkfh7R7JbVRrdquj L2aeO68I3+qHVo8w3AhkcACTLuAqE9InTpnoNlWJdykcKPAs+hBq938G1G7fD15BOYXN AdiJQWhypSmkaVxgwIHTlN3PV5hsCznKBicld77OcodHf1d5TW+Y/nVo1S3T5WB5ESMA CcKzXf/m1yzvzLXj5tF4chrP6yEgrPvopc29obNGPIuhmY4lA1sFqpSkG/xYUGo8LAus s/Co76JiIrmJV0dQqFjyak6y2Z4ay56JqbJTDhJG6/qCM2UaW7BiAk9Rq+H9hrCUpDDp dztw== X-Gm-Message-State: AA+aEWY1A0x17SnUetHPpdr7j0ytKRMgOoM/tjft/zojMcJjI+s/J73B ds9wvw0hCAwMlT6Ce0IoWQ35AGXqtIiT8myoWJySQRS4 X-Google-Smtp-Source: AFSGD/VCxF4NwtYD/DsRv1XkeA/Jk/N2VGBnTt9rdUKEfulUAQnPy7hlYydZtbSzqRQTZCF4+Fxth4q6pug2+J5bOMc= X-Received: by 2002:a02:9d27:: with SMTP id n36mr13636391jak.30.1544513211863; Mon, 10 Dec 2018 23:26:51 -0800 (PST) MIME-Version: 1.0 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> <95e6cab4-0668-4e0e-75a5-15fb876e1fe5@redhat.com> In-Reply-To: <95e6cab4-0668-4e0e-75a5-15fb876e1fe5@redhat.com> From: "David F." Date: Mon, 10 Dec 2018 23:26:40 -0800 Message-ID: To: Laszlo Ersek Cc: leif.lindholm@linaro.org, "Kinney, Michael D" , edk2 developers list X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Tue, 11 Dec 2018 07:26:53 -0000 Content-Type: text/plain; charset="UTF-8" I think leaving it in is fine, it is its own directory and everything will build with the build tools, when you start separating it, it may not build so easily. It already take a bit of processing and scripting to compile full blown apps ported to run on the direct UEFI platform (as well as BIOS, DOS, Linux, WIndows, etc..). On Mon, Dec 3, 2018 at 9:10 AM Laszlo Ersek wrote: > 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 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel >