Hi Andrew, Marvin, thanks for the explanation, I think I understand now.
@Andrew: Almost all command lines support the CTRL+C input to stop an executable from executing (https://en.wikipedia.org/wiki/Control-C). The EDKII Shell doesn't seem to support such thing, right? However, today it may be handled by the command/application (I think "dmpstore" does). But, as you said, the application must be able to release its resources, so it has to be terminated gracefully in any case. That would mean that CTRL+C can only work if the application supports it. Otherwise the Shell needs a lot more ressource management to support this in general. Nevertheless, this is a side story, so I don't need to discuss about that to the bitter end :) Cheers, Peter -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Gesendet: Mittwoch, 1. Juni 2016 18:49 An: Peter Kirmeier Cc: [email protected] Betreff: Re: [edk2] Q: Which module type fits my library? > On Jun 1, 2016, at 9:08 AM, Peter Kirmeier <[email protected]> wrote: > > Hi there, > > > > today I wasn't sure which module types my (DXE) library actually supports, > so I had a look at the modules writers guide here: > > https://github.com/tianocore-docs/Docs/raw/master/User_Docs/EDK_II%20Module% > 20Writer_s%20Guide_0_7.pdf > > At section 3.1.1 there is a list of module types with a brief introduction. > > So I was looking for suitable types. > > > > DXE_DRIVER is for DXE phase and gets destroyed after ExitBootServices. > > Okay. > > > > DXE_RUNTIME_DRIVER doesn't get destroyed but have to make sure the pointer > will not break on SetVirtualAddressMap(). > > Got it. > > > > UEFI_DRIVER is used for drivers that are "compliant with UEFI > Specification". What does that actually mean? > Peter, >From a UEFI Spec perspective for loading drivers/applications. The only difference between a driver and an application is the memory an application was loaded into is freed up after it returns, for a driver it is only freed if an error is returned (don't want protocols, events, etc. to go away). The only difference between runtime and boot services drivers is the type of memory that gets allocated for the image. DXE, PEI, SMM, etc are PI Spec concepts and not part of the UEFI spec. They are for platform construction and the support UEFI + PI specs. We don't want OS loaders and PCI Option ROMs depending on optional internal bits (DXE for example) so that is why there are separate types. Depex in the INF file is also a PI concept. No Depex in the INF of an UEFI Driver means that all the PI defined architectural protocols are present, so all the EFI services are fully functional. > I mean: Are they alive until ExitBootServices() or longer with the need to > take care of SetVirtualAddressMap()? > If an application calls ExitBootServices() it is basically an OS loader and it is taking over the system. > Haven't found any information about that yet, maybe someone can help here? > > > > UEFI_APPLICATION is used by applications which are "compliant with UEFI > Specification". > > Afaik this could be a bootloader, a shell oder a shell application, right? > Yes. > So I think the lifetime of this module starts and ends before > ExitBootServices() like a DXE_DRIVER. > Yes. > However, at least until the application is going to call ExitBootServices() > by itself or uses SetVirtualAddressMap(). > This assumes the application takes over from the firmware like an OS loader. None of the EFI services are valid, the pages tables are in memory that has been technically freed back to the OS etc. This is not a common environment as you don't have input/output devices or a place to log information. > Oh, and thinking of CTRL+C at shell it should be able to release all > resourses at any time, correct? > > Not sure what you are asking here? You have to write code to free allocated memory, there is no automatic freeing of memory when an application exits. Thanks, Andrew Fish > > Thank you, > > Peter > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
