From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
To: xen-devel@lists.xenproject.org
Cc: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>,
"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: [RFC PATCH 0/6] xen/abi: On wide bitfields inside primitive types
Date: Tue, 29 Oct 2024 18:16:26 +0000 [thread overview]
Message-ID: <20241029181632.69600-1-alejandro.vallejo@cloud.com> (raw)
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(-)
--
2.47.0
next reply other threads:[~2024-10-29 18:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 18:16 Alejandro Vallejo [this message]
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 ` [RFC PATCH 0/6] xen/abi: On wide bitfields inside primitive types Alejandro Vallejo
2024-10-30 8:45 ` 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=20241029181632.69600-1-alejandro.vallejo@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.