On 09/21/15 13:24, Stéphane Veyret wrote: > Hi Laszlo, > > > Thank you for your answer. > >>> but I made a >>> Gentoo ebuild for EDK2. >> >> For all of edk2, or OVMF? > > Only for EDK2 library,
EDK2 is not a library. It is a development kit. A collection of packages, which consist of modules. A module can be a library, a driver, or an application. Modules can be platform-dependent or platform-independent. Platform description files (more or less "makefiles") describe what modules to build and bundle into what firmware binaries. There are many libraries within EDK2, but EDK2 is not a library. There are also many possible platforms that can be built from, or on top of, EDK2. EDK2 has some platform description files within the three (eg. OvmfPkg/OvmfPkg*.dsc, ArmVirtPkg/ArmVirt*.dsc, EmulatorPkg/EmulatorPkg.dsc, DuetPkg/DuetPkg*.dsc) that build firmware binaries that can be executed on various platforms. But EDK2 as a "whole" cannot be built. It is a development kit. > which we find there: > https://github.com/tianocore/edk2 (do you have another name for it ?) > >> Also, I hope you're aware that edk2 / OVMF is not free software. Please >> see "FatBinPkg/License.txt". That's not necessarily a problem; it >> depends on whether you insist on distributing free software only. >> >> (Although, as I recall from my very-very brief stint in Gentoo, you >> might not be distributing edk2 at all -- only the ebuild files are >> distributed, which instructs each user's machine to download and build >> the package on the spot. Anyway, it's good to be aware of the FAT status.) > > Thank you, I was not aware of this specific FAT license. Anyway, > you're right in saying that I do not distribute EDK2, only the ebuild > in which there are instructions to download it directly from > SourceForge. What do you download? Upstream edk2 does not do releases. You can fetch the sourcecode from SVN or the semi-official git mirror on github. "UDK" is downloadable from sourceforge as a package; see eg. <http://www.tianocore.org/udk2014/>. "UDK2014 is a stable release of portions of the EDK II project." But I don't know why Gentoo users would want that, unless they have their own platform-dependent additional modules (like proprietary firmware developers do) that they maintain on top of UDK. > >>> This ebuild transforms a little bit the >>> installation >> >> How so? >> >>> in order to be able to use the product as is generally used a >>> library in Linux. >> >> I don't understand what this means. > > It is modified to use the usual linux tool chain, without calling the > specific EDK2 tools (parsing tools). For example, libraries are > renamed from LibraryName.lib to libLibraryName.a so they can be > directly called by linker using their name. Files are dispatched along > the directory structure where they should be (libraries, headers, > documents, samples and GenFw in the binary directory). I don't understand what this is good for. Let's take an edk2 library class as an example: TimerLib. The library class header file is MdePkg/Include/Library/TimerLib.h The following library instances *all* implement that interface: -------- ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf ArmPlatformPkg/Library/SP804TimerLib/SP804TimerLib.inf CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf DuetPkg/Library/DuetTimerLib/DuetTimerLib.inf EmulatorPkg/Library/DxeCoreTimerLib/DxeCoreTimerLib.inf EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.inf EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.inf MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf MdePkg/Library/DxeTimerLibEsal/DxeTimerLibEsal.inf MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf Omap35xxPkg/Library/Omap35xxTimerLib/Omap35xxTimerLib.inf OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf PerformancePkg/Library/TscTimerLib/BaseTscTimerLib.inf PerformancePkg/Library/TscTimerLib/DxeTscTimerLib.inf PerformancePkg/Library/TscTimerLib/PeiTscTimerLib.inf UefiCpuPkg/Library/SecPeiDxeTimerLibUefiCpu/SecPeiDxeTimerLibUefiCpu.inf Vlv2TbltDevicePkg/Library/IntelPchAcpiTimerLib/IntelPchAcpiTimerLib.inf -------- Now obviously UDK (if you download that) does not bundle all of these, but let's assume (I'm lazy to check) that it packages the three library instances from under MdePkg/Library, and the two instances from PcAtChipsetPkg/Library/AcpiTimerLib. These five library instances all implement the same set of functions that are declared in "MdePkg/Include/Library/TimerLib.h". But the implementations are extremely platform and environment dependent. With "environment", I also mean different phases of UEFI. Some library instances are appropriate only for some phases UEFI. Thus I don't understand how these libraries could be useful in a hosted, operating system-level environment, where your linker links applications and other libraries that are ultimately meant to run as user-space processes. Some libraries in EDK2 are platform-independent, yes, and implement generic algorithms and such. They could be used for hosted userspace programs, I guess, but the idea seems far-fetched. A plethora of user space-oriented data structures & algorithms libraries must exist for GNU/Linux (Glib, Qt, boost, etc), so I'm not sure why one would reach for edk2 to achieve the same. Or do you mean to build UEFI-targeted code (ie. firmware code), but with a toolset different from EDK2's BaseTools? Something like gnu-efi? If that's your use case, I don't think I could express support for it; albeit noble, I've always found gnu-efi unwieldy, in comparison to EDK2's BaseTools -- for the goal that BaseTools serves anyway. >>> Samples are also modified. >> >> What samples? > > HelloWorld.efi and other ones we have in MdeModulePkg/Application I think I'm getting more and more confused. :) - If you'd like to run these apps as hosted userspace Linux processes, then I don't see the use case. What is that good for? (BTW we already have EmulatorPkg for developing UEFI modules in such an environment.) - If you'd like to run these apps in a UEFI firmware environment, then I don't understand why they need to be modified; you can readily build them into EDK2 platforms. I wouldn't like to discourage you from packaging edk2 (tools? platforms?), but if it's confusing me, I'm worried that your users will be confused as well. What would you like to empower your users to do with this? For example, when we talk about packaging OVMF and/or ArmVirtPkg in Linux distros, we can say, "we'd like to empower our users to run UEFI payloads in QEMU/KVM and Xen guests, so they can develop for, test in, and play with, a UEFI environment on virtual hardware". Another example: the EDK2 community might justify distributing UDK with something like, "we'd like to empower our users, ie. firmware vendors for physical hardware systems, to develop their UEFI-compliant firmware on top of a central, (mostly) open source, reference implementation of the PI and UEFI specs". What is your excuse? :) Thanks Laszlo > > Regards, > > Stéphane. > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
