Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
> Am 10.09.2015 um 14:17 schrieb Andrew Fish <af...@apple.com>: > > >> 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. We're talking about replacing the non-free FAT driver with a free one for OVMF. The easiest path to get there isvto reuse an existing driver - the original proposal was to take the one from grub and fit it into uEFI's interfaces. An alternative to the GPL grub driver would be a BSD licensed driver from somewhere else or a rewrite. Rewrite sounds harder. If we can throw out the non-free FAT driver and put in a BSD licensed FAT driver based on known working code into edk2, I suppose it's a win for everyone involved and we wouldn't even need a fork for OVMF imho but keep it as reference implementation in the tree, like Duet. 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 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): > > http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15168 > >> 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 http://elm-chan.org/fsw/ff/00index_e.html 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. 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
> Am 10.09.2015 um 07:32 schrieb Jordan Justen: > > On 2015-09-09 20:26:54, Andrew Fish wrote: >>> On Sep 9, 2015, at 5:41 PM, Jordan Justen 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. Alex ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/8] current ACCESS_ONCE patch queue
On 15.01.15 09:58, Christian Borntraeger wrote: Folks, fyi, this is my current patch queue for the next merge window. It does contain a patch that will disallow ACCESS_ONCE on non-scalar types. The tree is part of linux-next and can be found at git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git linux-next KVM PPC bits are: Acked-by: Alexander Graf ag...@suse.de Alex ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Timed out waiting for device dev-hvc0.device.
On 12.12.14 01:25, manish jaggi wrote: On 11 December 2014 at 02:23, Julien Grall julien.gr...@linaro.org wrote: Hello, On 11/12/2014 02:27, manish jaggi wrote: I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs) ... [ OK ] Reached target Host and Network Name Lookups. [ OK ] Started OpenSSH Daemon. [ TIME ] Timed out waiting for device dev-hvc0.device. [DEPEND] Dependency failed for Serial Getty on hvc0. [ OK ] Reached target Login Prompts. Any Idea? what could be wrong here Please provide the full boot log. With only those 5 lines we can only guess what could be the issue. Added Maybe the DOM0 kernel didn't detect that it's running on Xen or you forgot to enable CONFIG_XEN_HVC in your config. That is already enabled. FYI with other rootfs I dont see any problem. Regards, -- Julien Grall [... Std linux boot log .. ] kjournald starting. Commit interval 5 seconds EXT3-fs (sda2): using internal journal EXT3-fs (sda2): mounted filesystem with writeback data mode VFS: Mounted root (ext3 filesystem) on device 8:2. devtmpfs: mounted Freeing unused kernel memory: 236K (ffc000789000 - ffc0007c4000) random: systemd urandom read with 4 bits of entropy available systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP +APPARMOR) systemd[1]: Detected virtualization 'xen'. systemd[1]: Detected architecture 'arm64'. Welcome to openSUSE 13.2 (Harlequin) (aarch64)! systemd[1]: Failed to insert module 'autofs4' systemd[1]: Failed to insert module 'ipv6' systemd[1]: Set hostname to linux. systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. systemd[1]: Expecting device dev-hvc0.device... Expecting device dev-hvc0.device... systemd[1]: Starting Remote File Systems (Pre). [ OK ] Reached target Remote File Systems (Pre). systemd[1]: Reached target Remote File Systems (Pre). systemd[1]: Starting Remote File Systems. [ OK ] Reached target Remote File Systems. systemd[1]: Reached target Remote File Systems. systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. systemd[1]: Starting Dispatch Password Requests to Console Directory Watch. systemd[1]: Started Dispatch Password Requests to Console Directory Watch. systemd[1]: Starting Paths. [ OK ] Reached target Paths. systemd[1]: Reached target Paths. systemd[1]: Starting Swap. [ OK ] Reached target Swap. systemd[1]: Reached target Swap. systemd[1]: Starting Root Slice. [ OK ] Created slice Root Slice. systemd[1]: Created slice Root Slice. systemd[1]: Starting udev Kernel Socket. [ OK ] Listening on udev Kernel Socket. systemd[1]: Listening on udev Kernel Socket. systemd[1]: Starting Journal Socket. [ OK ] Listening on Journal Socket. systemd[1]: Listening on Journal Socket. systemd[1]: Starting LVM2 metadata daemon socket. [ OK ] Listening on LVM2 metadata daemon socket. systemd[1]: Listening on LVM2 metadata daemon socket. systemd[1]: Starting /dev/initctl Compatibility Named Pipe. [ OK ] Listening on /dev/initctl Compatibility Named Pipe. systemd[1]: Listening on /dev/initctl Compatibility Named Pipe. systemd[1]: Starting Delayed Shutdown Socket. [ OK ] Listening on Delayed Shutdown Socket. systemd[1]: Listening on Delayed Shutdown Socket. systemd[1]: Starting Syslog Socket. [ OK ] Listening on Syslog Socket. systemd[1]: Listening on Syslog Socket. systemd[1]: Starting User and Session Slice. [ OK ] Created slice User and Session Slice. systemd[1]: Created slice User and Session Slice. systemd[1]: Starting System Slice. [ OK ] Created slice System Slice. systemd[1]: Created slice System Slice. systemd[1]: Started Create list of required static device nodes for the current kernel. systemd[1]: Starting Create static device nodes in /dev... Starting Create static device nodes in /dev... systemd[1]: Mounting POSIX Message Queue File System... Mounting POSIX Message Queue File System... systemd[1]: Mounting Debug File System... Mounting Debug File System... systemd[1]: Mounting Huge Pages File System... Mounting Huge Pages File System... systemd[1]: Starting Journal Service... Starting Journal Service... [ OK ] Started Journal Service. systemd[1]: Started Journal Service. [ OK ] Created slice system-serial\x2dgetty.slice. [ OK ] Created slice system-getty.slice. Starting LVM2 metadata daemon... Starting Load Kernel Modules... Starting Setup Virtual Console... Starting Remount Root and Kernel File Systems... Starting Create dynamic rule for /dev/root link... [ OK ] Reached target Slices. [ OK ] Listening on udev Control Socket. [ OK ] Mounted Huge Pages File System. [ OK ] Mounted
Re: [Xen-devel] Timed out waiting for device dev-hvc0.device.
On 12.12.14 02:20, manish jaggi wrote: On 11 December 2014 at 16:32, Alexander Graf ag...@suse.de wrote: On 12.12.14 01:25, manish jaggi wrote: On 11 December 2014 at 02:23, Julien Grall julien.gr...@linaro.org wrote: Hello, On 11/12/2014 02:27, manish jaggi wrote: I am facing this issue when booting Xen Dom0 (OpenSuse Rootfs) ... [ OK ] Reached target Host and Network Name Lookups. [ OK ] Started OpenSSH Daemon. [ TIME ] Timed out waiting for device dev-hvc0.device. [DEPEND] Dependency failed for Serial Getty on hvc0. [ OK ] Reached target Login Prompts. Any Idea? what could be wrong here Please provide the full boot log. With only those 5 lines we can only guess what could be the issue. Added Maybe the DOM0 kernel didn't detect that it's running on Xen or you forgot to enable CONFIG_XEN_HVC in your config. That is already enabled. FYI with other rootfs I dont see any problem. Regards, -- Julien Grall [... Std linux boot log .. ] kjournald starting. Commit interval 5 seconds EXT3-fs (sda2): using internal journal EXT3-fs (sda2): mounted filesystem with writeback data mode VFS: Mounted root (ext3 filesystem) on device 8:2. devtmpfs: mounted Freeing unused kernel memory: 236K (ffc000789000 - ffc0007c4000) random: systemd urandom read with 4 bits of entropy available systemd[1]: systemd 210 running in system mode. (+PAM -LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP +APPARMOR) systemd[1]: Detected virtualization 'xen'. systemd[1]: Detected architecture 'arm64'. Welcome to openSUSE 13.2 (Harlequin) (aarch64)! systemd[1]: Failed to insert module 'autofs4' systemd[1]: Failed to insert module 'ipv6' systemd[1]: Set hostname to linux. systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. systemd[1]: Expecting device dev-hvc0.device... Expecting device dev-hvc0.device... systemd[1]: Starting Remote File Systems (Pre). [ OK ] Reached target Remote File Systems (Pre). systemd[1]: Reached target Remote File Systems (Pre). systemd[1]: Starting Remote File Systems. [ OK ] Reached target Remote File Systems. systemd[1]: Reached target Remote File Systems. systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. systemd[1]: Starting Dispatch Password Requests to Console Directory Watch. systemd[1]: Started Dispatch Password Requests to Console Directory Watch. systemd[1]: Starting Paths. [ OK ] Reached target Paths. systemd[1]: Reached target Paths. systemd[1]: Starting Swap. [ OK ] Reached target Swap. systemd[1]: Reached target Swap. systemd[1]: Starting Root Slice. [ OK ] Created slice Root Slice. systemd[1]: Created slice Root Slice. systemd[1]: Starting udev Kernel Socket. [ OK ] Listening on udev Kernel Socket. systemd[1]: Listening on udev Kernel Socket. systemd[1]: Starting Journal Socket. [ OK ] Listening on Journal Socket. systemd[1]: Listening on Journal Socket. systemd[1]: Starting LVM2 metadata daemon socket. [ OK ] Listening on LVM2 metadata daemon socket. systemd[1]: Listening on LVM2 metadata daemon socket. systemd[1]: Starting /dev/initctl Compatibility Named Pipe. [ OK ] Listening on /dev/initctl Compatibility Named Pipe. systemd[1]: Listening on /dev/initctl Compatibility Named Pipe. systemd[1]: Starting Delayed Shutdown Socket. [ OK ] Listening on Delayed Shutdown Socket. systemd[1]: Listening on Delayed Shutdown Socket. systemd[1]: Starting Syslog Socket. [ OK ] Listening on Syslog Socket. systemd[1]: Listening on Syslog Socket. systemd[1]: Starting User and Session Slice. [ OK ] Created slice User and Session Slice. systemd[1]: Created slice User and Session Slice. systemd[1]: Starting System Slice. [ OK ] Created slice System Slice. systemd[1]: Created slice System Slice. systemd[1]: Started Create list of required static device nodes for the current kernel. systemd[1]: Starting Create static device nodes in /dev... Starting Create static device nodes in /dev... systemd[1]: Mounting POSIX Message Queue File System... Mounting POSIX Message Queue File System... systemd[1]: Mounting Debug File System... Mounting Debug File System... systemd[1]: Mounting Huge Pages File System... Mounting Huge Pages File System... systemd[1]: Starting Journal Service... Starting Journal Service... [ OK ] Started Journal Service. systemd[1]: Started Journal Service. [ OK ] Created slice system-serial\x2dgetty.slice. [ OK ] Created slice system-getty.slice. Starting LVM2 metadata daemon... Starting Load Kernel Modules... Starting Setup Virtual Console... Starting Remount Root and Kernel File Systems... Starting Create dynamic rule for /dev/root link... [ OK ] Reached target Slices