On Thu, Nov 09, 2023 at 06:40:34PM +0100, Thomas Huth wrote:
> Let's improve the wording here.
>
> Signed-off-by: Thomas Huth
> ---
> include/hw/xen/interface/hvm/params.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Daniel P. Berrangé
Wi
On Tue, Oct 10, 2023 at 02:41:22PM +0300, Dmitry Osipenko wrote:
> On 9/15/23 14:11, Huang Rui wrote:
> > Configure context init feature flag for virglrenderer.
> >
> > Originally-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > V4 -> V5:
> > - Inverted patch 5 and 6
On Tue, Jun 20, 2023 at 01:24:34PM -0400, Joel Upham wrote:
>
> Signed-off-by: Alexey Gerasimenko
This isn't a valid email address for Alexey - I presume you grabbed
these patches from the xen-devel mail archives, which have mangled
the addresses for anti-spam reasons.
Fortunately there are
On Mon, Mar 20, 2023 at 02:42:18PM +0100, Philippe Mathieu-Daudé wrote:
> By default, C function prototypes declared in headers are visible,
> so there is no need to declare them as 'extern' functions.
> Remove this redundancy in a single bulk commit; do not modify:
>
> - meson.build (used to
On Mon, Mar 06, 2023 at 02:25:46PM +, Daniel P. Berrangé wrote:
> On Mon, Mar 06, 2023 at 03:18:23PM +0100, Thomas Huth wrote:
> > On 06/03/2023 15.06, Daniel P. Berrangé wrote:
> > > On Mon, Mar 06, 2023 at 02:48:16PM +0100, Thomas Huth wrote:
> > > > On 06/03/
On Mon, Mar 06, 2023 at 03:18:23PM +0100, Thomas Huth wrote:
> On 06/03/2023 15.06, Daniel P. Berrangé wrote:
> > On Mon, Mar 06, 2023 at 02:48:16PM +0100, Thomas Huth wrote:
> > > On 06/03/2023 10.27, Daniel P. Berrangé wrote:
> > > > On Mon, Mar 06, 2023 at 09:46
On Mon, Mar 06, 2023 at 02:48:16PM +0100, Thomas Huth wrote:
> On 06/03/2023 10.27, Daniel P. Berrangé wrote:
> > On Mon, Mar 06, 2023 at 09:46:55AM +0100, Thomas Huth wrote:
> > > [...] If a 32-bit CPU guest
> > > +environment should be enforced, you can switch off the
On Mon, Mar 06, 2023 at 10:54:15AM +0100, Thomas Huth wrote:
> On 06/03/2023 10.27, Daniel P. Berrangé wrote:
> > On Mon, Mar 06, 2023 at 09:46:55AM +0100, Thomas Huth wrote:
> > > Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
> > > binary is a
qemu-system-i386 binary.
>
> With regards to 32-bit KVM support in the x86 Linux kernel,
> the developers confirmed that they do not need a recent
> qemu-system-i386 binary here:
>
> https://lore.kernel.org/kvm/y%2ffkts5ajfy0h...@google.com/
>
> Reviewed-by: Daniel
On Fri, Mar 03, 2023 at 12:31:42PM +0100, Thomas Huth wrote:
> On 03/03/2023 12.16, Peter Maydell wrote:
> > On Thu, 2 Mar 2023 at 16:31, Thomas Huth wrote:
> > >
> > > qemu-system-aarch64 is a proper superset of qemu-system-arm,
> > > and the latter was mainly still required for 32-bit KVM
> 1 file changed, 14 deletions(-)
Reviewed-by: Daniel P. Berrangé
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-phot
that anybody is still seriously using QEMU on a 32-bit arm
> CPU, so we deprecate the 32-bit arm hosts here to finally save use
> some time and precious CI minutes.
>
> Signed-off-by: Thomas Huth
> ---
> docs/about/deprecated.rst | 9 +
> 1 file changed, 9 insertions(+)
already, so we don't really need
> qemu-system-arm anymore, thus deprecated it now.
>
> Signed-off-by: Thomas Huth
> ---
> docs/about/deprecated.rst | 10 ++
> 1 file changed, 10 insertions(+)
Reviewed-by: Daniel P. Berrangé
With regards,
Daniel
--
|: https://
> 1 file changed, 16 deletions(-)
Reviewed-by: Daniel P. Berrangé
There's still the mingw 32-bit x86 build, but probably wolrth
keeping that until we actually stop 32-bit from a technical
POV, because Stefan still publishes the 32-bit windows
installers currently
Similarly the docker
> 32-bit stuff.
>
> Signed-off-by: Thomas Huth
> ---
> docs/about/deprecated.rst | 12
> 1 file changed, 12 insertions(+)
Reviewed-by: Daniel P. Berrangé
>
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 11700adac9..a30aa8dfdf 1
gt; ---
> docs/about/deprecated.rst | 12
> 1 file changed, 12 insertions(+)
Reviewed-by: Daniel P. Berrangé
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.ber
On Tue, Feb 28, 2023 at 06:24:02AM -0500, Michael S. Tsirkin wrote:
> On Tue, Feb 28, 2023 at 12:12:22PM +0100, Thomas Huth wrote:
> > On 28/02/2023 11.51, Michael S. Tsirkin wrote:
> > > On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
> > > > The question to answer: Is 32 bit
On Tue, Feb 28, 2023 at 10:14:52AM +0100, Thomas Huth wrote:
> On 28/02/2023 10.03, Michael S. Tsirkin wrote:
> > On Tue, Feb 28, 2023 at 08:59:52AM +0000, Daniel P. Berrangé wrote:
> > > On Tue, Feb 28, 2023 at 03:19:20AM -0500, Michael S. Tsirkin wrote:
> > > > On T
On Tue, Feb 28, 2023 at 08:39:49AM +0100, Thomas Huth wrote:
> On 27/02/2023 19.38, Daniel P. Berrangé wrote:
> > On Mon, Feb 27, 2023 at 12:10:48PM +0100, Thomas Huth wrote:
> > > We're struggling quite badly with our CI minutes on the shared
> > > gitlab runners, s
On Tue, Feb 28, 2023 at 03:19:20AM -0500, Michael S. Tsirkin wrote:
> On Tue, Feb 28, 2023 at 08:49:09AM +0100, Thomas Huth wrote:
> > On 27/02/2023 21.12, Michael S. Tsirkin wrote:
> > > On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
> > > &
On Mon, Feb 27, 2023 at 12:10:48PM +0100, Thomas Huth wrote:
> We're struggling quite badly with our CI minutes on the shared
> gitlab runners, so we urgently need to think of ways to cut down
> our supported build and target environments. qemu-system-i386 and
> qemu-system-arm are not really
On Mon, Feb 27, 2023 at 12:10:49PM +0100, Thomas Huth wrote:
> Hardly anybody still uses 32-bit x86 hosts today, so we should
> start deprecating them to finally have less test efforts.
> With regards to 32-bit KVM support in the x86 Linux kernel,
> the developers confirmed that they do not need a
On Thu, Dec 29, 2022 at 10:34:55AM +0100, Thomas Huth wrote:
> On 19/12/2022 14.02, Daniel P. Berrangé wrote:
> > Signed-off-by: Daniel P. Berrangé
> > ---
> > tests/qtest/ahci-test.c | 3 +++
> > tests/qtest/arm-cpu-features.c| 1 +
> > tests
Signed-off-by: Daniel P. Berrangé
---
tests/qtest/ahci-test.c | 3 +++
tests/qtest/arm-cpu-features.c| 1 +
tests/qtest/erst-test.c | 2 +-
tests/qtest/ide-test.c| 3 ++-
tests/qtest/ivshmem-test.c| 4 ++--
tests/qtest/libqmp.c | 2
Signed-off-by: Daniel P. Berrangé
---
tools/virtiofsd/fuse_log.c | 1 +
tools/virtiofsd/fuse_log.h | 6 --
tools/virtiofsd/passthrough_ll.c | 1 +
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/virtiofsd/fuse_log.c b/tools/virtiofsd/fuse_log.c
index
P. Berrangé
---
configure | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure b/configure
index 26c7bc5154..b9abe19e16 100755
--- a/configure
+++ b/configure
@@ -1208,6 +1208,8 @@ add_to warn_flags -Wnested-externs
add_to warn_flags -Wendif-labels
add_to warn_flags -Wexpansion
Signed-off-by: Daniel P. Berrangé
---
disas.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/disas.c b/disas.c
index 94d3b45042..31df8f5b89 100644
--- a/disas.c
+++ b/disas.c
@@ -239,6 +239,7 @@ void target_disas(FILE *out, CPUState *cpu, target_ulong
code,
}
}
+G_GNUC_PRINTF(2, 3
Signed-off-by: Daniel P. Berrangé
---
util/error-report.c | 1 +
util/error.c| 1 +
2 files changed, 2 insertions(+)
diff --git a/util/error-report.c b/util/error-report.c
index 5edb2e6040..6e44a55732 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -193,6 +193,7
G_GNUC_PRINTF / G_GNUC_SCANF to allow the code
locations that the compilers highlight. Then it adds the above
warning flags to the build flags, to catch any future additions
of functions that take printf/scanf format strings.
Daniel P. Berrangé (6):
disas: add G_GNUC_PRINTF to gstring_printf
hw/xen
Signed-off-by: Daniel P. Berrangé
---
hw/xen/xen-bus.c| 1 +
hw/xen/xen_pvdev.c | 1 +
include/hw/xen/xen-bus-helper.h | 6 --
include/hw/xen/xen-bus.h| 3 ++-
4 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen
On Thu, Oct 20, 2022 at 03:09:10PM +0200, Philippe Mathieu-Daudé wrote:
> On 20/10/22 11:16, Laurent Vivier wrote:
> > Use QIOChannel, QIOChannelSocket and QIONetListener.
> > This allows net/stream to use all the available parameters provided by
> > SocketAddress.
> >
> > Signed-off-by: Laurent
On Tue, Aug 02, 2022 at 01:39:31PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Aug 01, 2022 at 10:36:07AM +0100, Daniel P. Berrangé wrote:
> > Generally we want to see errors triggered from new enums arriving,
> > as it can be a sign that libvirt code needs a semantic chan
On Mon, Aug 01, 2022 at 09:51:11AM +0100, Julien Grall wrote:
> Hi Michal,
>
> On 01/08/2022 09:23, Michal Prívozník wrote:
> > On 7/29/22 17:50, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > Xen toolstack has gained basic Virtio support recently which becides
> > >
On Tue, Jun 14, 2022 at 11:40:38AM +0200, Gerd Hoffmann wrote:
> On Mon, Jun 13, 2022 at 08:52:21AM -0700, Richard Henderson wrote:
> > On 6/13/22 04:36, Gerd Hoffmann wrote:
> > > The following changes since commit
> > > dcb40541ebca7ec98a14d461593b3cd7282b4fac:
> > >
> > >Merge tag
On Sat, Jun 11, 2022 at 06:34:28PM +0200, Volker Rümelin wrote:
> Am 10.06.22 um 22:16 schrieb Richard Henderson:
> > On 6/10/22 02:20, Gerd Hoffmann wrote:
> > > The following changes since commit
> > > 9cc1bf1ebca550f8d90f967ccd2b6d2e00e81387:
> > >
> > > Merge tag 'pull-xen-20220609' of
> >
On Wed, Mar 16, 2022 at 01:52:48PM +0400, marcandre.lur...@redhat.com wrote:
> diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
> index 3baa5e3790f7..f2bd050e3b9a 100644
> --- a/include/qemu/compiler.h
> +++ b/include/qemu/compiler.h
> @@ -79,19 +79,12 @@
> #define
On Mon, Mar 14, 2022 at 05:52:32PM +0100, Markus Armbruster wrote:
> Peter Maydell writes:
>
> > On Mon, 14 Mar 2022 at 16:01, Markus Armbruster wrote:
> >>
> >> g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer,
> >> for two reasons. One, it catches multiplication
On Tue, Sep 14, 2021 at 01:30:27PM +, P J P wrote:
> Hello Philippe, all
>
> >On Thursday, 9 September, 2021, 03:58:40 pm IST, Daniel P. Berrangé
> > wrote:
> >On Thu, Sep 09, 2021 at 01:20:14AM +0200, Philippe Mathieu-Daudé wrote:
> >> This series is ex
On Thu, Sep 09, 2021 at 01:20:20AM +0200, Philippe Mathieu-Daudé wrote:
> Add DeviceClass::taints_security_policy field to allow an
> unsafe device to eventually taint the global security policy
> in DeviceRealize().
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw/qdev-core.h | 6
On Thu, Sep 09, 2021 at 11:40:07AM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 09, 2021 at 01:20:17AM +0200, Philippe Mathieu-Daudé wrote:
> > Add the BlockDriver::bdrv_taints_security_policy() handler.
> > Drivers implementing it might taint the global QEMU security
> > po
On Thu, Sep 09, 2021 at 01:20:17AM +0200, Philippe Mathieu-Daudé wrote:
> Add the BlockDriver::bdrv_taints_security_policy() handler.
> Drivers implementing it might taint the global QEMU security
> policy.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/block/block_int.h | 6 +-
>
On Thu, Sep 09, 2021 at 01:20:16AM +0200, Philippe Mathieu-Daudé wrote:
> Add the AccelClass::secure_policy_supported field to classify
> safe (within security boundary) vs unsafe accelerators.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/qemu/accel.h | 5 +
>
On Thu, Sep 09, 2021 at 01:20:14AM +0200, Philippe Mathieu-Daudé wrote:
> Hi,
>
> This series is experimental! The goal is to better limit the
> boundary of what code is considerated security critical, and
> what is less critical (but still important!).
>
> This approach was quickly discussed
On Mon, Dec 07, 2020 at 11:26:58AM +0100, Philippe Mathieu-Daudé wrote:
> On 12/7/20 11:25 AM, Daniel P. Berrangé wrote:
> > On Mon, Dec 07, 2020 at 06:46:01AM +0100, Thomas Huth wrote:
> >> On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote:
> >>> Cross-build s390x ta
On Mon, Dec 07, 2020 at 06:46:01AM +0100, Thomas Huth wrote:
> On 06/12/2020 19.55, Philippe Mathieu-Daudé wrote:
> > Cross-build s390x target with only KVM accelerator enabled.
> >
> > Signed-off-by: Philippe Mathieu-Daudé
> > ---
> > .gitlab-ci.d/crossbuilds-kvm-s390x.yml | 6 ++
> >
On Sun, Dec 06, 2020 at 07:55:00PM +0100, Philippe Mathieu-Daudé wrote:
> Hi,
>
> I was custom to use Travis-CI for testing KVM builds on s390x/ppc
> with the Travis-CI jobs.
>
> During October Travis-CI became unusable for me (extremely slow,
> see [1]). Then my free Travis account got updated
On Tue, Sep 22, 2020 at 08:56:06AM +0200, Paolo Bonzini wrote:
> On 22/09/20 08:45, David Hildenbrand wrote:
> >> It's certainly a good idea but it's quite verbose.
> >>
> >> What about using atomic__* as the prefix? It is not very common in QEMU
> >> but there are some cases (and I cannot think
: new patch in series v2
>
> ---
> Cc: Stefano Stabellini
> Cc: Anthony Perard
> Cc: Paul Durrant
> Cc: xen-devel@lists.xenproject.org
> Cc: qemu-de...@nongnu.org
> ---
> include/hw/xen/xen-legacy-backend.h | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-
On Thu, Jul 16, 2020 at 02:37:04PM +0200, Philippe Mathieu-Daudé wrote:
> Let blk_attach_dev() take an Error* object to return helpful
> information. Adapt the callers.
>
> $ qemu-system-arm -M n800
> qemu-system-arm: sd_init failed: cannot attach blk 'sd0' to device 'sd-card'
> blk 'sd0'
On Mon, Jul 06, 2020 at 09:31:21AM -0700, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20200706162300.1084753-1-dinec...@redhat.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> Subject: [PATCH]
On Mon, Jul 06, 2020 at 06:23:00PM +0200, Christophe de Dinechin wrote:
> There are a number of unnecessary trailing whitespaces that have
> accumulated over time in the source code. They cause stray changes
> in patches if you use tools that automatically remove them.
>
> Tested by doing a `git
On Wed, Jun 03, 2020 at 12:31:09PM +0200, Pavel Hrdina wrote:
> On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote:
> > Prior to 2621d48f005a "gnulib: delete all gnulib integration",
> > one could pass ./autogen.sh --no-git to prevent the libvirt build
> > system from running git
don't actively
cause problems for the QEMU build, removing them just makes
life more complex if you periodically refresh the headers with
new copies from future Xen releases.
Not a show stopper though - your choice as maintainer, so
Reviewed-by: Daniel P. Berrangé
>
> Signed-off-by: Anthony
ion
> - Revert problematic change instead.
>
> include/hw/xen/io/ring.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Daniel P. Berrangé
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: htt
On Tue, Jun 18, 2019 at 12:23:38PM +0100, Anthony PERARD wrote:
> Following 37677d7db3 "Clean up a few header guard symbols", QEMU start
> to fail to build:
>
> In file included from ~/xen/tools/../tools/include/xen/io/blkif.h:31:0,
> from
On Mon, Mar 04, 2019 at 04:42:32PM -0700, Jim Fehlig wrote:
> Adding xen-devel to cc in case anyone there wants to comment on my latest
> proposal...
>
> On 2/20/19 5:20 PM, Jim Fehlig wrote:
> > There have been a few requests [1][2] to support Xen's max_grant_frames
> > setting in libvirt
On Wed, Feb 20, 2019 at 11:53:42AM +0100, Marc-André Lureau wrote:
> Hi
>
> On Wed, Feb 20, 2019 at 2:02 AM Philippe Mathieu-Daudé
> wrote:
> >
> > Hi,
> >
> > This series convert the chardev::qemu_chr_write() to take unsigned
> > length argument. To do so I went through all caller and checked
On Wed, Feb 20, 2019 at 02:02:32AM +0100, Philippe Mathieu-Daudé wrote:
> diff --git a/include/chardev/char.h b/include/chardev/char.h
> index 0341dd1ba2..2e3b5a15ca 100644
> --- a/include/chardev/char.h
> +++ b/include/chardev/char.h
> @@ -221,7 +221,7 @@ void qemu_chr_set_feature(Chardev *chr,
| 4 +-
That you've finished tab-cleaning of these files, reinforces to
me that we should clean those other vnc files listed above.
None the less
Reviewed-by: Daniel P. Berrangé
since those ones mentioned above can still be done as a separate
commit to this.
Regards,
D
On Tue, Dec 11, 2018 at 02:57:29PM +, Liam Merwick wrote:
>
>
> On 11/12/2018 14:01, Stefan Hajnoczi wrote:
> > On Wed, Dec 05, 2018 at 10:37:24PM +, Liam Merwick wrote:
> > > From: Liam Merwick
> > >
> > > The x86/HVM direct boot ABI permits Qemu to be able to boot directly
> > > into
On Tue, Dec 11, 2018 at 10:34:52AM +, Peter Maydell wrote:
> On Tue, 25 Apr 2017 at 19:35, Stefano Stabellini
> wrote:
> >
> > From: Juergen Gross
> >
> > Instead of trying to guess the Xen version to use by compiling various
> > test programs first just ask the system via pkg-config. Only
On Fri, Dec 07, 2018 at 03:26:01PM +, Anthony PERARD wrote:
> On Fri, Dec 07, 2018 at 02:39:40PM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > > Sent: 07 December 2018 14:35
> > > To: Paul Durrant
> > > Cc:
ommit which
> introduced the race, but I'm not really sure how to fix it. Isn't this a
> bug in automake? :-)
The attractive big hammer solution is to stop using libtool entirely
and create shared libraries directly with gcc -shared, thus getting
rid of the stupid shell wrapper scripts &am
On Tue, May 08, 2018 at 03:50:49PM +0100, George Dunlap wrote:
> On Fri, May 4, 2018 at 10:00 PM, Daniel P. Berrangé <berra...@redhat.com>
> wrote:
> > CC'ing xen-devel in case Xen maintainers have a need for something that
> > will that conflict with this proposal wrt s
CC'ing xen-devel in case Xen maintainers have a need for something that
will that conflict with this proposal wrt supported build platforms.
On Fri, May 04, 2018 at 05:00:23PM +0100, Daniel P. Berrangé wrote:
> This short series is a followup the discussions around min glib version
> whe
On Tue, Apr 24, 2018 at 10:43:09AM -0500, Eric Blake wrote:
> On 04/24/2018 10:40 AM, Eric Blake wrote:
> > On 04/24/2018 10:18 AM, Daniel P. Berrangé wrote:
> >
> >>> - static void vreport(report_type type, const char *fmt, va_list ap)
> >>> + static void
On Tue, Apr 24, 2018 at 03:53:48PM +0100, Ian Jackson wrote:
> Philippe Mathieu-Daudé writes ("Re: [Qemu-devel] [PATCH 15/16] os-posix:
> cleanup: Replace perror with error_report"):
> > On 04/19/2018 01:45 PM, Ian Jackson wrote:
> > > -perror("mlockall");
> > > +
On Mon, Apr 23, 2018 at 05:21:42PM +0100, Anthony PERARD wrote:
> On Thu, Apr 19, 2018 at 05:45:19PM +0100, Ian Jackson wrote:
> > This makes it much easier to find a particular thing in config.log.
> >
> > The information may be lacking in other shells, resulting in harmless
> > empty output.
On Thu, Mar 22, 2018 at 09:27:55PM +0200, Michael S. Tsirkin wrote:
> Make sure all generated files go into qemu-build subdirectory.
> We can then include them like this:
> #include "qemu-build/trace.h"
>
> This serves two purposes:
> - make it easy to detect which files are in the source
>
On Wed, Mar 21, 2018 at 04:46:32PM +0200, Michael S. Tsirkin wrote:
> Our current scheme is to use
> #include ""
> for internal headers, and
> #include <>
> for external ones.
>
> Unfortunately this is not based on compiler support: from C point of
> view, the "" form merely looks up headers in
On Wed, Mar 21, 2018 at 03:08:36PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 21, 2018 at 08:16:00AM +0100, Thomas Huth wrote:
> > On 20.03.2018 13:05, Michael S. Tsirkin wrote:
> > > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> > >> Le 20/03/2018 à 02:54, Michael S.
On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
>
> Very large projects often split in sub projects, maybe one of them
> describing the API. Then that API headers are similar to system headers
> and can be included using <>, although they still belong to the same
> larger project. Do
On Tue, Mar 20, 2018 at 07:10:42PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> > Using <> for system include files and "" for local include files is a
> > convention, and as far as I know most projects adhere to that
> > convention. So does
On Tue, Mar 20, 2018 at 11:12:00AM -0500, Eric Blake wrote:
> On 03/19/2018 08:54 PM, Michael S. Tsirkin wrote:
> > QEMU coding style at the moment asks for all non-system
> > include files to be used with #include "foo.h".
>
> [I'm replying without having read the rest of the thread, so bear
On Tue, Mar 20, 2018 at 03:50:02PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 01:41:17PM +0000, Daniel P. Berrangé wrote:
> > On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > > So for these, we s
On Tue, Mar 20, 2018 at 02:32:16PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > So for these, we should use "". None of these are generated files though.
> >
> > That leads to crazy inconsistent message for developers where 50% of QEMU
> > header files must use <> and the other 50% of header
On Tue, Mar 20, 2018 at 02:28:42PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 12:18:41PM +0000, Daniel P. Berrangé wrote:
> > On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Mar 20, 2018 at 09:44:06AM +, Daniel P. Berrangé wro
On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 09:44:06AM +0000, Daniel P. Berrangé wrote:
> > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> > > Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> &g
On Tue, Mar 20, 2018 at 10:01:24AM +, Peter Maydell wrote:
> On 20 March 2018 at 09:44, Daniel P. Berrangé <berra...@redhat.com> wrote:
> > We can follow what autoconf does, and add a check to configure to see if
> > there are generated files left in the source
On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> > QEMU coding style at the moment asks for all non-system
> > include files to be used with #include "foo.h".
> > However this rule actually does not make sense and
> > creates
On Tue, Mar 13, 2018 at 09:37:55PM +1000, Alexey G wrote:
> On Tue, 13 Mar 2018 09:21:54 +
> Daniel P. Berrangé <berra...@redhat.com> wrote:
>
> >The subject line says to expect 30 patches, but you've only sent 18 to
> >the list here. I eventually figured out tha
On Tue, Mar 13, 2018 at 04:34:01AM +1000, Alexey Gerasimenko wrote:
> Current Xen/QEMU method to control Xen Platform device on i440 is a bit
> odd -- enabling/disabling Xen platform device actually modifies the QEMU
> emulated machine type, namely xenfv <--> pc.
>
> In order to avoid multiplying
The subject line says to expect 30 patches, but you've only sent 18 to
the list here. I eventually figured out that the first 12 patches were
in Xen code and so not sent to qemu-devel.
For future if you have changes that affect multiple completely separate
projects, send them as separate series.
83 matches
Mail list logo
