Re: [RFC] Proposal to add edk2-apps repository

["David F." <df7729@gmail.com>]

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 <lersek@redhat.com> 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
>