On 02/23/2013 01:17 PM, Mcdaniel, Daryl wrote: > OK. Let me paraphrase what I think you said in order to determine if > I understand the issues. > > Goal: Create a Linux distribution package (RPM, etc.) that, upon > installation, builds various UEFI modules and installs them into the > /boot partition, thus extending, updating, or replacing UEFI boot > files, drivers, or utilities.
Mostly. Your description doesn't clearly distinguish between binary and source packages, though. The binary package would just place a bunch of files (one or more .efi files, documentation files, and support files) in the Linux filesystem (and perhaps, but not necessarily, on the ESP). The source package includes source code that would create the binary package, using TianoCore as a library. Also, it's not really standard UEFI modules per se that are of interest, except to the extent that they're linked into the final application -- at least, not for me. (Somebody else might have other ideas, of course.) > Questions: Would a setup like is done for Linux kernel modules work? > The package you install references a previously installed > "kernel_dev" package that has the necessary headers and libraries. > The whole kernel source tree is not necessary but drivers, etc., can > be built. (replace "kernel" with "edk2" or "uefi" in solution) Probably; however, I'm not very familiar with developing Linux kernel drivers. > Is the "Boot Manager" that you are developing a UEFI application like > elilo and grub are? (as opposed to a Linux application manipulating > the UEFI boot environment) Yes, it's an EFI application. > Restate: So you, as a developer or software manufacturer, wish to be > able to distribute bits of UEFI firmware to be installed from Linux > into the EFI System partition (usually mounted as /boot or as a child > of /boot). I want to distribute an EFI application. I don't consider that to be EFI firmware, although of course it does link against TianoCore (or GNU-EFI's libraries). > To ensure platform compatibility, the firmware would be > built on the target system as part of the installation process. No. Most Linux distributions (Gentoo is an exception) distinguish between source packages and binary packages. Source packages include source code and are compiled into binary packages. End users typically need only install binary packages; but one of the key points is that source packages are available and MAY be compiled by end users into binary packages. Linux package systems typically enable ordinary (non-root) users to compile source packages, which is one reason why in-tree building is unworkable -- you can't assume that ordinary users (including developers) will be able to modify a library's (TianoCore's) tree. > It is unreasonable to include the entire EDK II or UDK2010 source tree > as part of the package. Correct. > It is desirable that the EDK II or UDK2010 > source tree not be required; just necessary headers. Ideally, yes; but that's not as critical. Currently, I've got an RPM version of rEFInd; but to build it against TianoCore, the entire TianoCore tree has to be installed. This is a consequence of the way TianoCore is distributed. When built against GNU-EFI, my rEFInd source RPM requires the GNU-EFI development package. This package installs four files in the /usr/lib64 directory and about two dozen header files. (Of course, a hypothetical TianoCore development RPM would install more files than this.) > The native > Linux build tools must be used to build the firmware. It would be > acceptable to also use tools installed as part of the "uefi-dev" > package that also provided the headers. Correct. > Am I correct or have I missed something? A clear description of the > problem and bounds of the solution set are necessary first steps to > solving the problem. I would like to help you provide a strong > argument for change or enhancement of the current tools. First, bear in mind that I didn't begin this thread, and I have a solution that works for me personally. It's unclear to me precisely why Daniel Cardin, who started this thread, wants out-of-tree building; I simply chimed in because my issue (which might or might not be similar to Daniel's) also requires out-of-tree building, and my solution might be an acceptable model for a solution for him. I don't want to distract from Daniel's needs, but I do know that other Linux developers, at least, have needs similar to mine, and TianoCore could be enhanced to help meet those needs.... Right now, I provide Makefiles that enable building rEFInd against either GNU-EFI or TianoCore, and it's possible to build a source RPM for rEFInd that builds against TianoCore when it's installed in the usual way. (I provide the necessary RPM .spec file with my source, in fact.) This works OK except that there's no RPM of TianoCore, AFAIK. The biggest problem in the status quo in terms of rEFInd is that a distribution maintainer will most likely end up compiling against GNU-EFI, and since GNU-EFI isn't as complete, there's one feature missing from rEFInd compiled in that way. Speaking more broadly, if you look at Linux-centric EFI projects (shim, gummiboot, ELILO, etc.), they all build against GNU-EFI rather than TianoCore (rEFInd being a partial exception), probably because of the lack of Linux-centric packaging for TianoCore, in the form of RPMs, Debian packages, and the equivalent for other distributions. Linux development of EFI applications could benefit from the creation of such packaging. The trick would be in doing this in a way that maximizes functionality for both Linux-style development of EFI applications and for building whole firmware systems or other tools that might require a package that integrates more of TianoCore. I don't claim to know enough about TianoCore to know how to balance these factors. Creating such changes would probably go well beyond Daniel's immediate needs, too. If you're interested in creating such packaging, I can help out; I'm competent (although by no means a guru) at creating RPM .spec files. The question is really where to place the hundreds of header, library, documentation, and support files so that they can be packaged in a Linux-like way without robbing functionality for those who want to use TianoCore in a more traditional (by TianoCore standards) way. > -----Original Message----- From: Rod Smith > [mailto:[email protected]] Sent: Friday, February 22, 2013 7:22 > PM To: [email protected] Subject: Re: [edk2] Projects > outside the edk directory structure > > On 02/22/2013 01:22 PM, Mcdaniel, Daryl wrote: >> IMHO, the easiest way to build a package or module that is not in >> the WORKSPACE tree is to use symbolic links and the standard EDK II >> build system. Create a symbolic link to your package in the root >> of $WORKSPACE or a link to your module within the using package. > > As I wrote when this topic came up three weeks ago, the approach you > suggest won't work when your goal is to create a program that's > compatible with inclusion in a Linux distribution. The issue is one > of the assumptions that the package systems (RPM, Debian packages, > ebuilds, etc.) make about where files go and what permissions they > have. Placing the source files for a specific package (rEFInd, in my > case) within a library's source directory (TianoCore's) simply cannot > be guaranteed in the build system -- at least, not as far as I know > for the package systems with which I'm familiar. Even dropping the > files elsewhere and creating symbolic links would be unreliable at > best because of permissions issues -- creating a symbolic link > requires write access within the TianoCore tree, but packages can be > built by ordinary users who might not have such access. Thus, a build > process that does not touch the library tree is a pre-requisite for > building in a way that's compatible with building as a Linux package. > The only way I can think of to build an EFI program in-tree with > TianoCore using RPM is to include the entire TianoCore tree as a > patch to the main program, and that's just plain ridiculous. > > Of course, this specific reason doesn't apply to every project. If > you're writing an EFI driver for a hardware device and have no reason > to distribute it with Linux, you probably don't care about building > Linux packages, and that's fine. I, OTOH, was developing a boot > manager that I wanted to be easy to distribute with Linux, so using a > Linux-friendly build process was high on my list of priorities. > Daniel Cardin, who started this thread, hasn't said why he wants to > build outside of the TianoCore tree, or even what platform he's > using, so it's hard to say what approach would work best for him. > -- Rod Smith [email protected] http://www.rodsbooks.com ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
