At 13:16 +0100 on 05 Mar (142555), Tim Deegan wrote:
At 11:55 + on 05 Mar (1425552955), Ian Campbell wrote:
On Thu, 2015-03-05 at 11:41 +, Jan Beulich wrote:
On 05.03.15 at 12:35, ian.campb...@citrix.com wrote:
On Thu, 2015-03-05 at 12:25 +0100, Tim Deegan wrote:
So I've
On 12.03.15 at 11:03, t...@xen.org wrote:
At 13:16 +0100 on 05 Mar (142555), Tim Deegan wrote:
At 11:55 + on 05 Mar (1425552955), Ian Campbell wrote:
On Thu, 2015-03-05 at 11:41 +, Jan Beulich wrote:
On 05.03.15 at 12:35, ian.campb...@citrix.com wrote:
On Thu, 2015-03-05
At 10:14 + on 12 Mar (1426151689), Ian Campbell wrote:
On Thu, 2015-03-12 at 11:03 +0100, Tim Deegan wrote:
At 13:16 +0100 on 05 Mar (142555), Tim Deegan wrote:
At 11:55 + on 05 Mar (1425552955), Ian Campbell wrote:
On Thu, 2015-03-05 at 11:41 +, Jan Beulich wrote:
On Thu, 2015-03-12 at 11:03 +0100, Tim Deegan wrote:
At 13:16 +0100 on 05 Mar (142555), Tim Deegan wrote:
At 11:55 + on 05 Mar (1425552955), Ian Campbell wrote:
On Thu, 2015-03-05 at 11:41 +, Jan Beulich wrote:
On 05.03.15 at 12:35, ian.campb...@citrix.com wrote:
On
On Thu, 2015-03-05 at 12:13 +, Wei Liu wrote:
Yes, mini-os now is just like any other Xen guests, which carries a copy
of all Xen public headers. Taking a new copy is OK.
Ah, I forgot you'd already done this. Super!
___
Xen-devel mailing list
On Thu, Mar 05, 2015 at 11:55:55AM +, Ian Campbell wrote:
On Thu, 2015-03-05 at 11:41 +, Jan Beulich wrote:
On 05.03.15 at 12:35, ian.campb...@citrix.com wrote:
On Thu, 2015-03-05 at 12:25 +0100, Tim Deegan wrote:
At 17:28 +0100 on 26 Feb (1424968122), Tim Deegan wrote:
BTW,
Add a check, like the existing check for non-ANSI C in the public
headers, that runs the public headers through a C++ compiler to
flag non-C++-friendly constructs.
Unlike the ANSI C check, we accept GCC-isms (gnu++98), and we also
check various tools-only headers.
Explicitly _not_ addressing the
On 26.02.15 at 17:28, t...@xen.org wrote:
At 16:11 + on 26 Feb (1424963496), Tim Deegan wrote:
Explicitly _not_ addressing the use of 'private' in various fields,
since we'd previously decided not to fix that.
BTW, ring.h is the only instance of that, so the extra diff to clear
that up
At 16:11 + on 26 Feb (1424963496), Tim Deegan wrote:
Add a check, like the existing check for non-ANSI C in the public
headers, that runs the public headers through a C++ compiler to
flag non-C++-friendly constructs.
Oops, this still has the EFI changes in it. v3, rebased, is on its way.
On 02/26/2015 07:01 PM, Tim Deegan wrote:
+#ifdef __cplusplus
+/* 'private' is a keyword in C++, so we have to use a different name for
+ * private state there. Leaving the C name alone to avoid unnecessary
+ * pain for the existing users. */
+#define XEN_RING_PRIVATE pvt
+#else
+#define
On 26/02/15 16:28, Tim Deegan wrote:
At 16:11 + on 26 Feb (1424963496), Tim Deegan wrote:
Add a check, like the existing check for non-ANSI C in the public
headers, that runs the public headers through a C++ compiler to
flag non-C++-friendly constructs.
Oops, this still has the EFI
At 16:47 + on 26 Feb (1424965651), Jan Beulich wrote:
On 26.02.15 at 17:28, t...@xen.org wrote:
At 16:11 + on 26 Feb (1424963496), Tim Deegan wrote:
Explicitly _not_ addressing the use of 'private' in various fields,
since we'd previously decided not to fix that.
BTW, ring.h
On 26/02/15 16:28, Tim Deegan wrote:
BTW, ring.h is the only instance of that, so the extra diff to clear
that up too is pretty small (see below).
Not sure what people think about that though - it might be
quite a PITA for downstream users of it, though they ought really to
be using local
On 02/26/15 14:22, Tim Deegan wrote:
At 19:49 +0200 on 26 Feb (1424976562), Razvan Cojocaru wrote:
On 02/26/2015 07:01 PM, Tim Deegan wrote:
+#ifdef __cplusplus
+/* 'private' is a keyword in C++, so we have to use a different name for
+ * private state there. Leaving the C name alone to
14 matches
Mail list logo
