On 29.04.2020 17:30, Julien Grall wrote:
> Hi Jan,
>
> On 29/04/2020 16:23, Jan Beulich wrote:
>> On 29.04.2020 17:06, Julien Grall wrote:
>>>
>>>
>>> On 29/04/2020 15:56, Jan Beulich wrote:
On 29.04.2020 16:14, Julien Grall wrote:
> Hi Jan,
>
> On 29/04/2020 15:05, Jan Beulich wr
Hi Jan,
On 29/04/2020 16:23, Jan Beulich wrote:
On 29.04.2020 17:06, Julien Grall wrote:
On 29/04/2020 15:56, Jan Beulich wrote:
On 29.04.2020 16:14, Julien Grall wrote:
Hi Jan,
On 29/04/2020 15:05, Jan Beulich wrote:
On 29.04.2020 16:01, Julien Grall wrote:
Hi,
On 22/04/2020 10:20, Jan
On 29.04.2020 17:06, Julien Grall wrote:
>
>
> On 29/04/2020 15:56, Jan Beulich wrote:
>> On 29.04.2020 16:14, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 29/04/2020 15:05, Jan Beulich wrote:
On 29.04.2020 16:01, Julien Grall wrote:
> Hi,
>
> On 22/04/2020 10:20, Jan Beulich wrote
On 29/04/2020 15:56, Jan Beulich wrote:
On 29.04.2020 16:14, Julien Grall wrote:
Hi Jan,
On 29/04/2020 15:05, Jan Beulich wrote:
On 29.04.2020 16:01, Julien Grall wrote:
Hi,
On 22/04/2020 10:20, Jan Beulich wrote:
Even if it was possible to use the sub-structs defined in the header
that
On 29.04.2020 16:14, Julien Grall wrote:
> Hi Jan,
>
> On 29/04/2020 15:05, Jan Beulich wrote:
>> On 29.04.2020 16:01, Julien Grall wrote:
>>> Hi,
>>>
>>> On 22/04/2020 10:20, Jan Beulich wrote:
> Even if it was possible to use the sub-structs defined in the header
> that way, keep in mind
Hi Jan,
On 29/04/2020 15:05, Jan Beulich wrote:
On 29.04.2020 16:01, Julien Grall wrote:
Hi,
On 22/04/2020 10:20, Jan Beulich wrote:
Even if it was possible to use the sub-structs defined in the header
that way, keep in mind that we also wrote:
/* dummy member to force sizeof(struc
On 29.04.2020 16:01, Julien Grall wrote:
> Hi,
>
> On 22/04/2020 10:20, Jan Beulich wrote:
>>> Even if it was possible to use the sub-structs defined in the header
>>> that way, keep in mind that we also wrote:
>>>
>>> /* dummy member to force sizeof(struct xen_pvcalls_request)
>>>
Hi,
On 22/04/2020 10:20, Jan Beulich wrote:
Even if it was possible to use the sub-structs defined in the header
that way, keep in mind that we also wrote:
/* dummy member to force sizeof(struct xen_pvcalls_request)
* to match across archs */
struct xen_pvcalls_dummy
On 22.04.2020 01:27, Stefano Stabellini wrote:
> On Mon, 20 Apr 2020, Jan Beulich wrote:
>> On 20.04.2020 15:34, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 20/04/2020 09:04, Jan Beulich wrote:
On 19.04.2020 12:49, Julien Grall wrote:
> --- a/docs/misc/pvcalls.pandoc
> +++ b/docs/misc/p
On Mon, 20 Apr 2020, Jan Beulich wrote:
> On 20.04.2020 15:34, Julien Grall wrote:
> > Hi Jan,
> >
> > On 20/04/2020 09:04, Jan Beulich wrote:
> >> On 19.04.2020 12:49, Julien Grall wrote:
> >>> --- a/docs/misc/pvcalls.pandoc
> >>> +++ b/docs/misc/pvcalls.pandoc
> >>> @@ -246,9 +246,7 @@ The forma
On 20.04.2020 15:34, Julien Grall wrote:
> Hi Jan,
>
> On 20/04/2020 09:04, Jan Beulich wrote:
>> On 19.04.2020 12:49, Julien Grall wrote:
>>> --- a/docs/misc/pvcalls.pandoc
>>> +++ b/docs/misc/pvcalls.pandoc
>>> @@ -246,9 +246,7 @@ The format is defined as follows:
>>> uint32_t
Hi Jan,
On 20/04/2020 09:04, Jan Beulich wrote:
On 19.04.2020 12:49, Julien Grall wrote:
--- a/docs/misc/pvcalls.pandoc
+++ b/docs/misc/pvcalls.pandoc
@@ -246,9 +246,7 @@ The format is defined as follows:
uint32_t domain;
uint32_t type;
On 19.04.2020 12:49, Julien Grall wrote:
> --- a/docs/misc/pvcalls.pandoc
> +++ b/docs/misc/pvcalls.pandoc
> @@ -246,9 +246,7 @@ The format is defined as follows:
> uint32_t domain;
> uint32_t type;
> uint32_t protocol;
> -
From: Julien Grall
The documentation of pvcalls only describes the padding for i386. This
is a bit odd as there are some implicit padding for 64-bit (e.g in
xen_pvcalls_release) and this doesn't cater other 32-bit arch.
Remove the #ifdef in the documentation to show the padding is present on
all
14 matches
Mail list logo
