qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, Michael Roth <michael.roth@amd.com>,
	Konstantin Kostiuk <kkostiuk@redhat.com>
Subject: Re: [PATCH 04/14] qapi: add a 'command-features' pragma
Date: Fri, 12 Jul 2024 10:17:07 +0100	[thread overview]
Message-ID: <ZpD0k8taHT00jZpX@redhat.com> (raw)
In-Reply-To: <87a5inuh75.fsf@pond.sub.org>

On Fri, Jul 12, 2024 at 10:50:54AM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Fri, Jul 12, 2024 at 10:07:34AM +0200, Markus Armbruster wrote:
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >> 
> >> > The 'command-features' pragma allows for defining additional
> >> > special features that are unique to a particular QAPI schema
> >> > instance and its implementation.
> >> 
> >> So far, we have special features (predefined, known to the generator and
> >> treated specially), and normal features (user-defined, not known to the
> >> generator).  You create a new kind in between: user-defined, not known
> >> to the generator, yet treated specially (I guess?).  Hmm.
> >> 
> >> Could you at least hint at indented use here?  What special treatment do
> >> you have in mind?
> >
> > Essentially, these features are a way to attach metadata to commands that
> > the server side impl can later query. This eliminates the need to hardcode
> > lists of commands, such as in QGA which hardcodes a list of commands which
> > are safe to use when filesystems are frozen. This is illustrated later in
> > this series.
> 
> Please update docs/devel/qapi-code-gen.rst section "Pragma directives",
> and maybe section "Features".
> 
> I'm not sure conflating the new kind of feature with existing special
> features is a good idea.  I need to review more of the series before I
> can make up my mind.

I originally implemented a completely separate 'tags' concept in the
QAPI parser, before deciding I was just re-inventing 'features' for
no obvious benefit.

The other nice thing about using features is that these are exposed
in the schema and docs. With the 'fsfreeze' restriction in code,
there's no formal docs of what commands are allowed when frozen, and
this is also not exposed in QAPI schema to apps. Using 'features'
we get all that as standard.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2024-07-12  9:18 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04 15:32 [PATCH 00/14] Improve mechanism for configuring allowed commands Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 01/14] qapi: use "QAPI_FEATURE" as namespace for special features Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 02/14] qapi: add helper for checking if a command feature is set Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 03/14] qapi: cope with special feature names containing a '-' Daniel P. Berrangé
2024-07-12  7:54   ` Markus Armbruster
2024-06-04 15:32 ` [PATCH 04/14] qapi: add a 'command-features' pragma Daniel P. Berrangé
2024-07-12  8:07   ` Markus Armbruster
2024-07-12  8:12     ` Daniel P. Berrangé
2024-07-12  8:50       ` Markus Armbruster
2024-07-12  9:17         ` Daniel P. Berrangé [this message]
2024-07-16 18:08           ` Markus Armbruster
2024-07-17 10:46             ` Daniel P. Berrangé
2024-07-17 11:43               ` Markus Armbruster
2024-06-04 15:32 ` [PATCH 05/14] qapi: stop hardcoding list of special features Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 06/14] qapi: define enum for custom special features on commands Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 07/14] qga: use special feature to mark those that can run when FS are frozen Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 08/14] qga: add command line to limit commands for confidential guests Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 09/14] qga: define commands which can be run in confidential mode Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 10/14] qga: add command line to block unrestricted command/file access Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 11/14] qga: mark guest-file-* commands with 'unrestricted' flag Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 12/14] qga: mark guest-exec-* " Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 13/14] qga: add command line to block user authentication commands Daniel P. Berrangé
2024-06-04 15:32 ` [PATCH 14/14] qga: mark guest-ssh-* / guest-*-password commands with 'unrestricted' flag Daniel P. Berrangé
2024-07-02 18:09 ` [PATCH 00/14] Improve mechanism for configuring allowed commands Daniel P. Berrangé
2024-07-15  9:52 ` Markus Armbruster
2024-07-15 10:56   ` Daniel P. Berrangé

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=ZpD0k8taHT00jZpX@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kkostiuk@redhat.com \
    --cc=michael.roth@amd.com \
    --cc=qemu-devel@nongnu.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).