All of lore.kernel.org
 help / color / mirror / Atom feed
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



             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.