From: Jan Beulich <jbeulich@suse.com>
To: Julien Grall <julien@xen.org>
Cc: Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
paul@xen.org, Andrew Cooper <andrew.cooper3@citrix.com>,
Julien Grall <jgrall@amazon.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches
Date: Tue, 16 Jun 2020 11:36:13 +0200 [thread overview]
Message-ID: <0dd2ffb5-88ff-114f-6127-5bbcc5eed1ae@suse.com> (raw)
In-Reply-To: <035d1085-c08c-3dee-6e9b-faf245ef660d@xen.org>
On 16.06.2020 11:19, Julien Grall wrote:
>
>
> On 16/06/2020 09:26, Jan Beulich wrote:
>> On 13.06.2020 20:41, Julien Grall wrote:
>>> @@ -73,10 +76,18 @@ struct xen_pvcalls_request {
>>> uint32_t flags;
>>> grant_ref_t ref;
>>> uint32_t evtchn;
>>> +#ifndef __i386__
>>> + uint8_t pad[4];
>>> +#endif
>>
>> Where possible I think uint32_t would be slightly better to use.
>
> OOI, why?
Because everything else here uses the wider type, plus the
question of why use a compound type (array) when a simple
one does.
>>
>>> } connect;
>>> struct xen_pvcalls_release {
>>> uint64_t id;
>>> uint8_t reuse;
>>> +#ifndef __i386__
>>> + uint8_t pad[7];
>>> +#else
>>> + uint8_t pad[3];
>>> +#endif
>>
>> For this I'd recommend uniform "uint8_t pad[3];" (i.e. outside
>> of any #ifdef) followed by a uint32_t again inside the #ifdef.
>
> Same question here. The more the padding cannot be re-used.
>
>>
>> Expressing everything through e.g. alignof() would seem even
>> better, but I can't currently think of a way to do so cleanly.
>
> I am afraid I don't have time to look at how alignof() can work nicely.
> Feel free to send a follow-up or pick-up the patch is you really want
> alignof().
I didn't mean to ask that you find a solution. I merely pointed
out that expressing things properly rather than using hard coded
numbers would be nice.
Jan
next prev parent reply other threads:[~2020-06-16 9:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-13 18:41 [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches Julien Grall
2020-06-15 8:26 ` Paul Durrant
2020-06-16 1:00 ` Stefano Stabellini
2020-06-16 7:13 ` Jan Beulich
2020-06-16 9:39 ` Julien Grall
2020-06-16 20:57 ` Stefano Stabellini
2020-06-16 21:31 ` Julien Grall
2020-06-18 1:34 ` Stefano Stabellini
2020-06-18 15:00 ` Julien Grall
2020-06-24 11:29 ` [INPUT REQUESTED][PATCH " Julien Grall
2020-06-24 12:05 ` Ian Jackson
2020-06-24 12:04 ` [PATCH " Ian Jackson
2020-06-26 17:46 ` Julien Grall
2020-06-16 8:26 ` Jan Beulich
2020-06-16 9:19 ` Julien Grall
2020-06-16 9:36 ` Jan Beulich [this message]
2020-06-16 9:42 ` Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0dd2ffb5-88ff-114f-6127-5bbcc5eed1ae@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jgrall@amazon.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=paul@xen.org \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).