From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>,
<xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Jan Beulich" <jbeulich@suse.com>,
"Julien Grall" <julien@xen.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Juergen Gross" <jgross@suse.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
"Christian Lindig" <christian.lindig@citrix.com>,
"David Scott" <dave@recoil.org>,
"Bertrand Marquis" <bertrand.marquis@arm.com>,
"Michal Orzel" <michal.orzel@amd.com>,
"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [RFC PATCH 0/6] xen/abi: On wide bitfields inside primitive types
Date: Tue, 29 Oct 2024 18:29:46 +0000 [thread overview]
Message-ID: <D58I4WS083OC.3JTJQC57GIDXT@cloud.com> (raw)
In-Reply-To: <20241029181632.69600-1-alejandro.vallejo@cloud.com>
On Tue Oct 29, 2024 at 6:16 PM GMT, Alejandro Vallejo wrote:
> Non-boolean bitfields in the hypercall ABI make it fairly inconvenient to
> create bindings for any language because (a) they are always ad-hoc and are
> subject to restrictions regular fields are not (b) require boilerplate that
> regular fields do not and (c) might not even be part of the core language,
> forcing avoidable external libraries into any sort of generic library.
>
> This patch (it's a series merely to split roughly by maintainer) is one such
> case that I happened to spot while playing around. It's the grant_version
> field, buried under an otherwise empty grant_opts.
>
> The invariant I'd like to (slowly) introduce and discuss is that fields may
> have bitflags (e.g: a packed array of booleans indexed by some enumerated
> type), but not be mixed with wider fields in the same primitive type. This
> ensures any field containing an integer of any kind can be referred by pointer
> and treated the same way as any other with regards to sizeof() and the like.
>
> I'd like to have a certain consensus about this general point before going
> establishing this restriction in the IDL system I'm working on.
>
> My preference would be to fold everything into a single patch if we decide to
> follow through with this particular case. As I said before, the split is
> artificial for review.
>
> Alejandro Vallejo (6):
> xen/domctl: Refine grant_opts into grant_version
> tools: Rename grant_opts to grant_version
> tools/ocaml: Rename grant_opts to grant_version
> xen/arm: Rename grant_opts to grant_version
> xen/x86: Rename grant_opts to grant_version
> xen/common: Rename grant_opts to grant_version
>
> tools/helpers/init-xenstore-domain.c | 2 +-
> tools/libs/light/libxl_create.c | 2 +-
> tools/ocaml/libs/xc/xenctrl_stubs.c | 3 +--
> tools/python/xen/lowlevel/xc/xc.c | 2 +-
> tools/tests/paging-mempool/test-paging-mempool.c | 2 +-
> tools/tests/resource/test-resource.c | 6 +++---
> tools/tests/tsx/test-tsx.c | 4 ++--
> xen/arch/arm/dom0less-build.c | 4 ++--
> xen/arch/arm/domain_build.c | 2 +-
> xen/arch/x86/setup.c | 2 +-
> xen/common/domain.c | 6 +++---
> xen/common/grant_table.c | 3 +--
> xen/include/public/domctl.h | 15 +++++++++++----
> xen/include/xen/grant_table.h | 4 ++--
> 14 files changed, 31 insertions(+), 26 deletions(-)
Bah. I sent it too early. The new field in patches 2-6 ought to be
max_grant_version. Regardless, the general point still holds, I hope.
Cheers,
Alejandro
next prev parent reply other threads:[~2024-10-29 18:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 18:16 [RFC PATCH 0/6] xen/abi: On wide bitfields inside primitive types Alejandro Vallejo
2024-10-29 18:16 ` [RFC PATCH 1/6] xen/domctl: Refine grant_opts into grant_version Alejandro Vallejo
2024-10-30 9:08 ` Jan Beulich
2024-10-30 13:58 ` Alejandro Vallejo
2024-10-29 18:16 ` [RFC PATCH 2/6] tools: Rename grant_opts to grant_version Alejandro Vallejo
2024-10-29 18:16 ` [RFC PATCH 3/6] tools/ocaml: " Alejandro Vallejo
2024-10-29 18:16 ` [RFC PATCH 4/6] xen/arm: " Alejandro Vallejo
2024-10-29 18:16 ` [RFC PATCH 5/6] xen/x86: " Alejandro Vallejo
2024-10-29 18:16 ` [RFC PATCH 6/6] xen/common: " Alejandro Vallejo
2024-10-29 18:29 ` Alejandro Vallejo [this message]
2024-10-30 8:45 ` [RFC PATCH 0/6] xen/abi: On wide bitfields inside primitive types Christian Lindig
2024-10-30 14:02 ` Alejandro Vallejo
2024-10-30 9:14 ` Jan Beulich
2024-10-30 15:08 ` Alejandro Vallejo
2024-10-31 7:57 ` Jan Beulich
2024-10-31 13:55 ` Alejandro Vallejo
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=D58I4WS083OC.3JTJQC57GIDXT@cloud.com \
--to=alejandro.vallejo@cloud.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=bertrand.marquis@arm.com \
--cc=christian.lindig@citrix.com \
--cc=dave@recoil.org \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=marmarek@invisiblethingslab.com \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.