On Mon, Feb 26, 2018 at 1:32 PM, Peter Maydell wrote:
> Paragraph (3) isn't saying "BSD license is special",
> it's saying "the TCG codegen code is special" -- it's a theoretically
> well-defined reusable subset of code that has its own tighter standards
> for what license we accept (see also tcg/
On 26 February 2018 at 12:03, Daniel P. Berrangé wrote:
> Eeek, I totally missed that as the top level LICENSE file only mentions
> GPL and BSD licenses :-( I guess that's a trigger for a patch to improve
> the text in the LICENSE file to better reflect reality...
Paragraph (2) says "Parts of QE
On Mon, Feb 26, 2018 at 11:57:10AM +, Peter Maydell wrote:
> On 26 February 2018 at 10:47, Daniel P. Berrangé wrote:
> > I accept that MIT is compatible with GPLv2+, so that's not an immediate
> > legal
> > problem. The issue is that as we add more & more different licenses to QEMU,
> > it be
On 26 February 2018 at 10:47, Daniel P. Berrangé wrote:
> I accept that MIT is compatible with GPLv2+, so that's not an immediate legal
> problem. The issue is that as we add more & more different licenses to QEMU,
> it becomes a maintenance burden to developers, especially when doing code
> refac
This is being used to build openSUSE Factory for riscv64 with linux-user
emulation:
https://build.opensuse.org/project/show/openSUSE:Factory:RISCV
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for somethin
If anyone wants a simple way to test this, grab the latest bbl &
stage4 disk image from here and boot it under qemu-system-riscv64
using the command line given in the readme.txt file:
https://fedorapeople.org/groups/risc-v/disk-images/
I've added v6 to Fedora copr, and switched to using it for
On Sat, Feb 24, 2018 at 09:05:49AM +1300, Michael Clark wrote:
> Dear Daniel,
>
> We've had this discussion on a recent pull request where some code was
> going to be copied directly from hw/arm/virt.c to hw/riscv/virt.c and we
> have subsequently relicensed the recipient file as GPLv2+. This code
On Sat, Feb 24, 2018 at 10:31 AM, Richard Henderson <
richard.hender...@linaro.org> wrote:
> On 02/22/2018 04:11 PM, Michael Clark wrote:
> > QEMU RISC-V Emulation Support (RV64GC, RV32GC)
> >
> > This is hopefully the "fix remaining issues in-tree" release.
>
> FWIW, I'm happy with this.
>
> For
On 02/22/2018 04:11 PM, Michael Clark wrote:
> QEMU RISC-V Emulation Support (RV64GC, RV32GC)
>
> This is hopefully the "fix remaining issues in-tree" release.
FWIW, I'm happy with this.
For those patches that I haven't given an explicit R-b, e.g. most of hw/, I
didn't see anything obviously wro
Dear Daniel,
We've had this discussion on a recent pull request where some code was
going to be copied directly from hw/arm/virt.c to hw/riscv/virt.c and we
have subsequently relicensed the recipient file as GPLv2+. This code has
not yet been incorporated into the port. Besides naming conventions
On Fri, Feb 23, 2018 at 01:11:46PM +1300, Michael Clark wrote:
> QEMU RISC-V Emulation Support (RV64GC, RV32GC)
>
> This is hopefully the "fix remaining issues in-tree" release.
This code seems to be a mixture of LGPLv2+ and MIT licensed code. The
preferred license for QEMU contributions is GPLv2
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1519344729-73482-1-git-send-email-...@sifive.com
Subject: [Qemu-devel] [PATCH v6 00/23] RISC-V QEMU Port Submission
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total
12 matches
Mail list logo
