Re: [Xen-devel] [edk2] edk2 compile error
> On Sep 17, 2016, at 8:38 PM, Chen, Farrah <farrah.c...@intel.com> wrote: > > Hi, > > When I compile xen with the latest commit in RHEL 6.7, it failed when make > tools. Errors showed when running edk2 build for OvmfPkgX64. > Bisected and this error occurred from commit > 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2. > > commit 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2 > Author: Wei Liu <wei.l...@citrix.com<mailto:wei.l...@citrix.com>> > Date: Tue Sep 6 12:54:47 2016 +0100 > >Config.mk: update OVMF commit > > Signed-off-by: Wei Liu wei.l...@citrix.com<mailto:wei.l...@citrix.com> > > > We have updated OVMF to the latest master and cleaned everything before > rebuilding. > > > > Steps: > > make clean > > make xen -j8 > > ./configure --enable-ovmf > > make tools -j8 > > Then the error occurred. > > > > > > I also tried: > > git clone https://github.com/tianocore/edk2.git > > cd edk2 > > OvmfPkg/build.sh -a X64 -b DEBUG -n 4 > The same error occurred. > . > > log: > .. > Running edk2 build for OvmfPkgX64 > .. > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:173: > error: invalid combination of opcode and operands > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:175: > error: invalid combination of opcode and operands > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:177: > error: invalid combination of opcode and operands > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:179: > error: invalid combination of opcode and operands > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:313: > error: invalid combination of opcode and operands > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:315: > error: invalid combination of opcode and operands Can you attach a copy of the failing ExceptionHandlerAsm.iii as it is the output of the preprocessor. Thanks, Andrew Fish > make[7]: Leaving directory > `/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib' > make[7]: *** > [/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.obj] > Error 1 > > > build.py... > : error 7000: Failed to execute command >make tbuild > [/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib] > > > build.py... > : error F002: Failed to build module > > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf > [X64, GCC44, DEBUG] > > - Failed - > > > Thanks, > Fan Chen > > > ___ > edk2-devel mailing list > edk2-de...@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] [PATCH v2] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM
> On Jun 24, 2016, at 7:50 PM, Shannon Zhao <zhaoshengl...@huawei.com> wrote:
>
>
>
> On 2016/6/23 21:42, Ard Biesheuvel wrote:
>>>> + //
>>>> + // Get the RSDP structure address from DeviceTree
>>>> + //
>>>> + Status = gBS->LocateProtocol (, NULL,
>> Please add gFdtClientProtocolGuid to the [Depex] section of this module
>>
> Hi Ard,
>
> I try to add gFdtClientProtocolGuid to the [Depex] but I got a compiling
> error.
>
> build.py...
> : error F001: Invalid dependency expression: missing operator before {
> 0xE11FACA0, 0x4710, 0x4C8E, { 0xA7, 0xA2, 0x01, 0xBA, 0xA2, 0x59, 0x1B,
> 0x4C } }
>Near { 0xFFE06BDD, 0x6107, 0x46A6, { 0x7B, 0xB2, 0x5A, 0x9C,
> 0x7E, 0xC5, 0x27, 0x5C }}
>
That is not a common error. Can you attach you INF file? It sounds like a
syntax error in the [Depex]?
Thanks,
Andrew Fish
> How to deal with this problem?
>
> Thanks,
> --
> Shannon
>
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
> On Sep 10, 2015, at 4:40 AM, Alexander Graf <ag...@suse.de> wrote: > > > > On 10.09.15 12:04, Laszlo Ersek wrote: >> On 09/10/15 08:19, Alexander Graf wrote: >>> >>> >>>> Am 10.09.2015 um 07:32 schrieb Jordan Justen <jordan.l.jus...@intel.com>: >> >>>> Laszlo's email raised the GPL question, but I was not sure what the >>>> EDK II community would accept with regards to GPL. Thus ... I asked. I >>>> guess I'm getting a better idea with regards to Apple and HP. :) >>>> >>>> In your opinion, would we be able to discuss patches for a *separate* >>>> repo with GplDriverPkg on edk2-devel? >>> >>> In fact, could we just make the non-free FAT source and GPL FAT >>> source both be git submodules? >> >> We've discussed submodules in the past (for other purposes). The >> consensus seemed to be that most people dislike them (me included). >> >> UEFI drivers are supposed to be modular / well separable (for one, they >> can be shipped by third parties in binary-only form; which was a design >> goal of UEFI). And specifically in the FAT driver's case, the source >> doesn't even live inside the main repo at the moment, so turning it into >> a source submodule might not be a step back. >> >> But... I just don't like it. We should be moving towards a grand unified >> repo, where cross-module changes and dependencies are possible to >> implement with carefully segmented patch sets. The FAT driver's source >> lives outside for non-technical reasons. Rather than codifying that >> situation forever with a git submodule, I'd prefer some solution that >> leaves us with a standalone repo. >> >> I think I'm fuzzy on the details of the earlier git-submodule >> discussion. In any case here's the link (I hope this is the right one): >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__thread.gmane.org_gmane.comp.bios.tianocore.devel_15168=BQID-g=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o=VQx-tNIhMX_CI4DXORkNq10jBTMAXyaFT332GWZhfRQ= >> >> >>> Then whoever clones the repo can get >>> the license flavor he's least scared about. >> >> I think for many companies it is important that a developer of theirs >> who is "blissfully ignorant" of licensing questions simply *cannot* make >> a mistake (eg. by copying code from the "wrong" directory, or by using >> the "wrong" submodule). It should be foolproof. >> >>> Or alternatively instead >>> of pulling in a GPL licensed FAT driver we use a BSD licensed one. >>> I'm sure someone has one of those too ;). >> >> I'm not sure at all. Do you have a pointer? :) > > Well, the BSDs definitely have drivers, but I find the BSD VFS layer > quite confusing to be honest ;). > > Then there is > https://urldefense.proofpoint.com/v2/url?u=http-3A__elm-2Dchan.org_fsw_ff_00index-5Fe.html=BQID-g=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o=l2F5kQrmSHyEb7D4po7B0A-vQK1l7rCkw79eJCddVmQ= > which from my > gut feeling has a compatible license (read: needs verification). > > I'm sure with some extensive search one can find a workable driver. Or > for example Apple could just contribute theirs as BSD licensed. > They are talking about an EFI FAT driver with a BSD compatible license, not a BSD driver. The edk2 EFI FAT driver has a license that matches the FAT32 spec it was coded against, but that license restricts the usage of the code to EFI. This is not deemed a GPL compatible license, so that causes issues with down stream GPL projects of the edk2 as there is a binary for the EFI FAT driver checked into the main branch of the edk2. The source to the edk2 EFI FAT driver is separate from the edk2 based on its funky license. Thanks, Andrew Fish > > Alex ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
> On Sep 10, 2015, at 8:44 PM, Kevin Davis <kevin.da...@insyde.com> wrote: > >> >> On 09/10/2015 08:14 PM, Kevin Davis wrote: >>>> >>> Ah. I wasn't in the room when they figured it out. And I've never seen >> their written opinion. Is it documented somewhere? >> >> which in turn leads to this FAQ: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__web.archive.org_web_20121116185559_http-3A__lkml.org_lkml_2009_6_=BQIGaQ=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=mhYwzTqxMG2tM5He0exVnKYSFG58txsY87BTZP3pIqo=LKChPDVsVauW8_4ZGz2OukddijAHxwPZhnjeXQZCW5I= >> >> 26/314 >> >> So reading between the lines, IBM's opinion was that implementing a >> workaround that operates FAT in such a way that it never uses a common >> namespace was sufficient to avoid any legal questions about whether that >> code conflicts with a patent on a common namespace, sidestepping the >> longer question of any legal battle over the patent itself. >> > > Of course I have no comment on the legal opinion other than it is interesting > and nice to have a pointer to it. > > Thanks for the pointers > This history of issues is why we should remove the binary FAT driver from the common repo, so we accommodate the realities of all the down stream partners. Thanks, Andrew Fish PS Nice to see the FOSS and traditional PC folks learning from each other on the list. >> -- >> Eric Blake eblake redhat com+1-919-301-3266 >> Libvirt virtualization library >> https://urldefense.proofpoint.com/v2/url?u=http-3A__libvirt.org=BQIGaQ=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=mhYwzTqxMG2tM5He0exVnKYSFG58txsY87BTZP3pIqo=-yJzLpdTqQeS_UK_JwAuIFrCqfdN48GJH6q_ljHnfI8= >> > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
> On Sep 9, 2015, at 11:19 PM, Alexander Graf <ag...@suse.de> wrote: > > > >> Am 10.09.2015 um 07:32 schrieb Jordan Justen <jordan.l.jus...@intel.com>: >> >> On 2015-09-09 20:26:54, Andrew Fish wrote: >>>> On Sep 9, 2015, at 5:41 PM, Jordan Justen <jordan.l.jus...@intel.com> >>>> wrote: >>>>> On 2015-09-09 16:05:20, Andrew Fish wrote: >>>>> So you have a legal degree and are speaking on behalf of your >>>>> employer on this subject? >>>> >>>> No and no. How about you? :) >>> >>> No but I have to review any code contributed to the open source >>> project to make sure it follows the corporate polices. >> >> Is Apple corporate policy that you could never contribute to a project >> that has a GPL directory in the tree? >> >>>> Nevertheless, I have not heard the interpretation that just having GPL >>>> in a source tree would impact your code, even if you do not include, >>>> nor link to it. Is this Apple's interpretation of how GPL works? >>> >>> No but thanks for making my point for me. 1st off the rules are made >>> by lawyers and managers so you trying to argue logic is kind of >>> funny. What does logic have to do with it. >> >> Whoa! What's next in this crazy world? Dogs and cats living together! >> Mass hysteria! How can we be sure that the lawyers won't decide that >> BSD means GPL and vice versa? ;) >> >>> Your company started this edk2 project as a BSD project, and I >>> assume there was a reason for that. >> >> And then more licenses were added. >> >>> The reasons rules like this end up getting made is that developers >>> like you are confused about the company policy regarding open >>> source, closed source and protecting intellectual property rights. >>> So your very smart and well versed and you are confused, so >> >> I don't think I'm confused (or smart :), but you are trying hard to >> make it seem confusing and scary. >> >> Anyway, you are correct. We do have rules. But, I don't think those >> rules prevent us from discussing *possible* changes to those rules. >> >>> some more jr. engineer has no hope of getting it right and would >>> copy the GPL code and be clueless to what he just did. As I always >>> say a development process exists to slow down the best developer, at >>> the price of preventing the most jr. developers from doing something >>> stupid. >> >> If we have another repo with GplDriverPkg, then I guess the same jr. >> developer might just go find the code over there and copy it. >> >>>> I would be more worried about the GPL based drivers becoming too >>>> featureful over time, and the permissively licensed code not being >>>> very useful. For example, I'm worried that the non-GPL OVMF may end up >>>> missing a lot of features. >>> >>> Then logically you should just make OVMF a GPL project? >> >> Not if you are someone that prefers permissive source licenses, such >> as myself. >> >> I'm basically trying to argue the other side of this to not let the >> GPL FUD go by unimpeded. >> >> Laszlo's email raised the GPL question, but I was not sure what the >> EDK II community would accept with regards to GPL. Thus ... I asked. I >> guess I'm getting a better idea with regards to Apple and HP. :) >> >> In your opinion, would we be able to discuss patches for a *separate* >> repo with GplDriverPkg on edk2-devel? > > In fact, could we just make the non-free FAT source and GPL FAT source both > be git submodules? Then whoever clones the repo can get the license flavor > he's least scared about. Or alternatively instead of pulling in a GPL > licensed FAT driver we use a BSD licensed one. I'm sure someone has one of > those too ;). > > Also for the record, the FAT driver problem is that the source license states > that it can not be used in certain circumstances, which by common > interpretation makes it non-free. The fact that there is a binary or source > doesn't matter fwiw. > The edk2 FAT driver solves the problems faced by folks shipping hardware, but the source ended up as a separate project to keep the license clean. I don’t think anyone thought about the binary + license being an issue back in the day? IMHO the right thing to do is remove the binary FAT driver from the tree (the source is already in a sub project), and update the getting started collateral. It seems like the right thing to do to respect folks with different down stream licensing constraints. I wish those of us with BSD development constraints got the same consideration from some of the GPL developers on this list. Thanks, Andrew Fish > > Alex > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
> On Sep 9, 2015, at 10:57 AM, Jordan Justen <jordan.l.jus...@intel.com> wrote: > > On 2015-09-09 10:04:50, Andrew Fish wrote: >> >>> On Sep 9, 2015, at 9:17 AM, Jordan Justen <jordan.l.jus...@intel.com> wrote: >>> >>> So, related to this, I wonder how the community would feel about a >>> GplDriverPkg. Would the community allow it as a new package in EDK II >>> directly, or would a separate repo be required? >>> >> >> I think we would need a separate repo, like the FAT driver. That is >> the only way to deal with the license issues. > > There doesn't seem to be any guiding rules here. For example, I think > some people are not comfortable with the FatBinPkg being in the tree > due to the license. I don’t think it is fair to look backwards to make this comparison A long time ago your co-workers decided to check some binaries in to make folks life easier. 1) Tools compiled by VC++ that only run on Windows 2) Shell binary 3) FAT binary I think the goal was one svn pull and no extra tools needed to install, build, and run NT32 on Windows. The source code was BSD so other than the FAT driver it is all compatible with a GPL project that wanted to import the code. That was good enough when this decision was made. I personally have no issue removing the binaries from the tree, especially the FAT driver if it causes issues for folks. I think that would imply the website, and any getting started collateral would need to get updated. > Why is that okay? > It was OK, at the time. The intellectual property around FAT is a mess, but at least it is permissible to use it in (U)EFI to boot a system. >>> With regards to adding it directly into the EDK II tree, here are some >>> potential concerns that I might anticipate hearing from the community: >>> >>> * It will make it easier for contributors to choose GPL compared to a >>> permissive license, thereby limiting some users of the contribution >>> >>> * GPL code will more easily be copied into the permissively licensed >>> packages >>> >>> * Some might refuse to look at EDK II entirely if it has a directory >>> with GPL source code in it >>> >> >> Or have their rights to contribute revoked since this is a >> fundamental change, and would require employees to get reauthorized >> by their legal departments to contribute. > > We've recently expanded beyond just allowing BSD code into the tree, > and that appeared to be no big deal. No one brought this up as a > fundamental change. > > Just to be clear, are you saying Apple probably won't be able to > contribute to EDK II if there is any GPL licensed code in the tree? > (Even if it is contained in a clearly indicated package.) I guess > using dual-licensed BSD/GPL is okay though? > (EmbeddedPkg/Library/FdtLib) > BSD compatible is OK. Thanks, Andrew Fish > -Jordan > ___ > edk2-devel mailing list > edk2-de...@lists.01.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=Kmc0BLQJkt9XKCJf_d8PrrQXQ9eNhkkTmN6cq2RzIzo=gmyUS4K6xDQ0QIZyAv_DkOp_G9rMBrDpvqa_VV_4RTo= > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
> On Sep 9, 2015, at 3:24 PM, Jordan Justen <jordan.l.jus...@intel.com> wrote: > > On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote: >> The recent expansions beyond BSD where all permissive licenses (BSD >> like) as far as I can tell. >> >> I agree with Andrew, opening the door for GPL licensed code in EDK2 >> will have severe consequences for products that are built using >> EDK2. > > I don't think simply having a GplDriverPkg in the tree would have any > consequences for a platform that doesn't use any code in that package. > Obviously we could not make any core packages rely on that package. > So you have a legal degree and are speaking on behalf of your employer on this subject? > This would just be a sanctioned, clear landing place for people that > cannot, or will not provide their driver under a permissive license. > > This license will limit who can use drivers from this package. For > that reason, I hope that we will always ask if a contribution can be > permissively licensed instead. > > Personally, I would prefer a 2-clause BSD only tree for simplicity, > but unfortunately, that sort of restriction has its own drawbacks as > well. (frustrated contributors and less contributions) > > FWIW, I don't mind if the consensus is that GplDriverPkg must live in > a separate repo. But, it would be nice to hear a good reason why it > must live elsewhere. Because GPL is not a permissive license. An accidental git grep and copying some code can change the license of the code that gets the GPL code pasted into it. Thus having GPL code in the same repository as BSD code can end up accidentally converting BSD code to GPL code over time. If GPL was OK with everyone we would have started with GPL. The good thing is the BDS code is GPL compatible so it can be used for GPL code and bug fixes in the BDS code can be merged into to GPL code, but this is a one way operation. If you don’t believe me please feel free to sit down and have a long conversation with Intel IP lawyers. > (And, why that doesn't also apply to FatBinPkg.) > There is no IP leakage from a binary. This FAT driver is licensed for use with EFI, and given this is a EFI code base that seemed like a good thing. I don’t pretent to understand the GPL FAT thing, I guess it is some kind of civil disobedience. it does not mater what license you strap on the code the the device makers still have to “pay the man”. Thanks, Andrew Fish PS As I stated before I’m fine removing all the binaries from the main repo, as you don’t really want binaries in your production repo, and source level debugging is a nice feature and all. > -Jordan > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Jordan Justen >> Sent: Wednesday, September 09, 2015 12:58 PM >> To: Andrew Fish <af...@apple.com> >> Cc: Lenny Szubowicz <lenn...@redhat.com>; Karen Noel <kn...@redhat.com>; Ard >> Biesheuvel <ard.biesheu...@linaro.org>; edk2-devel-01 >> <edk2-de...@lists.01.org>; Reza Jelveh <reza.jel...@tuhh.de>; Alexander Graf >> <ag...@suse.de>; qemu devel list <qemu-de...@nongnu.org>; Hannes Reinecke >> <h...@suse.de>; Gabriel L. Somlo (GMail) <gso...@gmail.com>; Peter Jones >> <pjo...@redhat.com>; Peter Batard <p...@akeo.ie>; Gerd Hoffmann >> <kra...@redhat.com>; Cole Robinson <crobi...@redhat.com>; Paolo Bonzini >> <pbonz...@redhat.com>; xen-devel@lists.xen.org; Laszlo Ersek >> <ler...@redhat.com>; Ademar de Souza Reis Jr. <ar...@redhat.com> >> Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015 >> >> On 2015-09-09 10:04:50, Andrew Fish wrote: >>> >>>> On Sep 9, 2015, at 9:17 AM, Jordan Justen <jordan.l.jus...@intel.com> >>>> wrote: >>>> >>>> So, related to this, I wonder how the community would feel about a >>>> GplDriverPkg. Would the community allow it as a new package in EDK >>>> II directly, or would a separate repo be required? >>>> >>> >>> I think we would need a separate repo, like the FAT driver. That is >>> the only way to deal with the license issues. >> >> There doesn't seem to be any guiding rules here. For example, I >> think some people are not comfortable with the FatBinPkg being in >> the tree due to the license. Why is that okay? >> >>>> With regards to adding it directly into the EDK II tree, here are >>>> some potential concerns that I might anticipate hearing from the community: >>>> >>>> * It will make it easier fo
Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
> On Sep 9, 2015, at 5:41 PM, Jordan Justen <jordan.l.jus...@intel.com> wrote: > > On 2015-09-09 16:05:20, Andrew Fish wrote: >> >>> On Sep 9, 2015, at 3:24 PM, Jordan Justen <jordan.l.jus...@intel.com> wrote: >>> >>> On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote: >>>> The recent expansions beyond BSD where all permissive licenses (BSD >>>> like) as far as I can tell. >>>> >>>> I agree with Andrew, opening the door for GPL licensed code in EDK2 >>>> will have severe consequences for products that are built using >>>> EDK2. >>> >>> I don't think simply having a GplDriverPkg in the tree would have any >>> consequences for a platform that doesn't use any code in that package. >>> Obviously we could not make any core packages rely on that package. >>> >> >> So you have a legal degree and are speaking on behalf of your >> employer on this subject? > > No and no. How about you? :) > No but I have to review any code contributed to the open source project to make sure it follows the corporate polices. > Nevertheless, I have not heard the interpretation that just having GPL > in a source tree would impact your code, even if you do not include, > nor link to it. Is this Apple's interpretation of how GPL works? > No but thanks for making my point for me. 1st off the rules are made by lawyers and managers so you trying to argue logic is kind of funny. What does logic have to do with it. Your company started this edk2 project as a BSD project, and I assume there was a reason for that. The reasons rules like this end up getting made is that developers like you are confused about the company policy regarding open source, closed source and protecting intellectual property rights. So your very smart and well versed and you are confused, so some more jr. engineer has no hope of getting it right and would copy the GPL code and be clueless to what he just did. As I always say a development process exists to slow down the best developer, at the price of preventing the most jr. developers from doing something stupid. >>> FWIW, I don't mind if the consensus is that GplDriverPkg must live in >>> a separate repo. But, it would be nice to hear a good reason why it >>> must live elsewhere. >> >> Because GPL is not a permissive license. An accidental git grep and >> copying some code can change the license of the code that gets the >> GPL code pasted into it. > > I like this argument. It is slightly tempered by the fact that git > grep always shows the source path, and thus 'GplDriverPkg' would be > obviously visible. > If the developer is even paying attention, or using a tool that highlights path vs. filename. Or maybe the path is too long to display and gets shortened in a way that Gpl is not obvious. Not to mention if this was so easy why not include the source for the FAT driver with the GPL sources? We could add EvilNonGplCompatibleLicence to the path and that would solve everything. >> Thus having GPL code in the same repository as BSD code can end up >> accidentally converting BSD code to GPL code over time. > > I would be more worried about the GPL based drivers becoming too > featureful over time, and the permissively licensed code not being > very useful. For example, I'm worried that the non-GPL OVMF may end up > missing a lot of features. > Then logically you should just make OVMF a GPL project? Thanks, Andrew Fish > -Jordan > ___ > edk2-devel mailing list > edk2-de...@lists.01.org <mailto:edk2-de...@lists.01.org> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=QYa4zV8t1IKrqv8dzBT9QGeAY0RWiBcTz1WwIesvScU=nVrllStzjUOtvIbFx2GiI-npvnVHMREDrHQ1CcfBD2E= > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=QYa4zV8t1IKrqv8dzBT9QGeAY0RWiBcTz1WwIesvScU=nVrllStzjUOtvIbFx2GiI-npvnVHMREDrHQ1CcfBD2E=> ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
> On Sep 9, 2015, at 9:17 AM, Jordan Justen <jordan.l.jus...@intel.com> wrote: > > On 2015-09-09 01:57:51, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task list, after some off-list discussion (I tried >> to incorporate comments): >> >> - create GPL'd fork called "ovmf" for expediting virt development >> (OvmfPkg, ArmVirtPkg) >> - maybe leverage the feature under >> >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__permalink.gmane.org_gmane.comp.bios.edk2.devel_941=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA=NkAF9nkaYv90MC55j7jme4YajlZK14oKVu3L61jRnJ4= >> > for >>setting up a separate "tianocore/edk2-gpl" repo, for GPL'd >>contributions [Jordan] >>- repo separation by license could make things harder for packagers >> and QEMU bundling [Laszlo] > > I would like OVMF to follow a plan for GPL that the whole EDK II > community decides on. > > I would also like to see EDK II add a (permissively licensed; BSD, > MIT, etc) DriverPkg (DriversPkg?). We discussed this on the list > recently: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__thread.gmane.org_gmane.comp.bios.tianocore.devel_17544_focus-3D676=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA=HauTLYzaQYz935VMYQCCR8xzuSADw1ZcWSSjSyEXIpw= > > > So, related to this, I wonder how the community would feel about a > GplDriverPkg. Would the community allow it as a new package in EDK II > directly, or would a separate repo be required? > I think we would need a separate repo, like the FAT driver. That is the only way to deal with the license issues. > With regards to adding it directly into the EDK II tree, here are some > potential concerns that I might anticipate hearing from the community: > > * It will make it easier for contributors to choose GPL compared to a > permissive license, thereby limiting some users of the contribution > > * GPL code will more easily be copied into the permissively licensed > packages > > * Some might refuse to look at EDK II entirely if it has a directory > with GPL source code in it > Or have their rights to contribute revoked since this is a fundamental change, and would require employees to get reauthorized by their legal departments to contribute. > Of these, I personally only sympathize with the first. > Your employer probably has issues with all of this. > Regarding the separate OVMF repo, my hope is that it is more of a OVMF > specific working area, rather than a 'GPL OVMF'. For example, patches > or features that we've not yet figured out how to upstream, but we > hopefully plan to. > Mixing is never going to work. If you mix then the pure BSD edk2 will fork and continue, I’m guessing a lot of the Intel resources will work on that version as it will be the one enabling Intel products. > Additionally, it makes sense to use it as needed for OVMF specific > releases. (Ie, OVMF release tags) > Seems to me we are really solving the wrong problem. What we need is a smaller BSD edk2 project that supports the industry standards and works on some set of BSD platforms. There can be down stream consumers that have more platform support, and different licenses. Seems the real problem is the unpredictable changes to MdePkg libraries, and MdeModulePkg infrastructure. So it is the lack of a transparent plan, and discussion about upcoming changes that break compatibility between different projects. So the solution is to keep everything in the tree working on master. We should fix the edk2 process, and place a process in place to communicate pending non backward compatible changes in the edk2 to down stream consumers. Don’t forget a lot (majority) of edk2 based products that ship today live in a separate repo that likely contains a UDK or specific version of edk2 with cherry picked patches. So this processes is kind of already happening in the non-GPL world…. Thanks, Andrew Fish > -Jordan > >> - document the rules / justification for "ovmf" (licensing >> conflicts, non-technical blockage on edk2 etc). >> - No new mailing list needed >> - push RH's downstream-only patches to "ovmf", wherever that makes >> sense >> - remove encumbered FAT driver >> - import Peter Batard's GPL r/o FAT driver port of GRUB's >> - secure OpenSSL linking exception for the former from the copyright >> holders (Peter Batard, GRUB project) >> - "ovmf" should be periodically rebased / should fetch+mer
Re: [Xen-devel] [edk2] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled
On Feb 14, 2015, at 1:04 PM, Laszlo Ersek ler...@redhat.com wrote: On 02/14/15 21:03, Jordan Justen wrote: On 2015-02-14 08:38:37, Laszlo Ersek wrote: On 02/12/15 21:53, Jordan Justen wrote: I think gEfiPciEnumerationCompleteProtocolGuid should be installed by MdeModulePkg/Bus/Pci/PciBusDxe, even when PcdPciDisableBusEnumeration is set. Ray's main feedback seemed to be that we need to make sure PciBusDxe only installs the protocol once. (I'll also reply to the other related patch thread.) First, I now agree that this patch of mine should not go in, hence: Self-NAK Second, I tend to disagree that that gEfiPciEnumerationCompleteProtocolGuid should be installed even if full enumeration was eschewed. This might slightly change the de-facto meaning of the protocol (because no resource allocation took place). De-facto seems the correct term here, since the PI1.2 spec says very little about the protocol. My interpretation of the protocol is that it is a signal that the EFI knows about the basic PCI topology, and has installed most PciIo instances. Maybe PcdPciDisableBusEnumeration wasn't the best name. Perhaps PcdPciBusPreEnumerated would have been better. At any rate, in the case of Xen, the hypervisor has pre-enumerated the bus. PciBusDxe uses this and 'enumerates' PCI devices by simply scanning the pre-enumerated topology. So, I still think PciBusDxe should install gEfiPciEnumerationCompleteProtocolGuid, because it still seems like it acurately reflects the phase of the boot process. Regarding the ACPI tables issue, would a callback for the ReadyToBoot event work? EFI_EVENT_GROUP_READY_TO_BOOT This event group is notified by the system when the Boot Manager is about to load and execute a boot option. (1) As far as I understand, if you boot a UEFI application, then exit it, and boot something else, then the event group will be signalled each time. We could use a static variable in AcpiPlatformDxe to avoid trying to install again and again, but it wouldn't be nice IMHO. You can always use a global. This is the secondary reason I'm not enthusiastic about EFI_EVENT_GROUP_READY_TO_BOOT. :) (2) The main reason is different: in both OVMF and ArmVirtualizationQemu we can boot a kernel directly, taken from QEMU. That happens without EFI_EVENT_GROUP_READY_TO_BOOT being signalled. However, the kernel booted thus should have both ACPI tables and configured PCI devices (if there is a PCI host). In OVMF this is ensured by: PlatformBdsPolicyBehavior() PlatformBdsConnectSequence() BdsLibConnectAll() TryRunningQemuKernel() where the BdsLibConnectAll() call listed above will cover the enumeration, and trigger the dependent ACPI table installation as well, before we go to the kernel. One idea could be to signal EFI_EVENT_GROUP_READY_TO_BOOT ourselves, That sounds like the right thing to do. before booting the kernel; however this event group seems quite tied to the Boot Manager itself (see again its definition above). The Boot Manager has a few responsibilities in EFI (and few more in PI where it is called the BDS), but in general it is a place where a lot of platform specific policy is enforced. So updating the Boot Manager do do the right thing sees like a good answer. Thanks, Andrew Fish I'll post my patch series soon; my idea that is relevant for this discussion is at its beginning (and a later patch also displays how I mean it to be used). We can discuss it there too if you like. Thanks Laszlo -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ http://goparallel.sourceforge.net/ ___ edk2-devel mailing list edk2-de...@lists.sourceforge.net mailto:edk2-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel https://lists.sourceforge.net/lists/listinfo/edk2-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
