KVM Archive on lore.kernel.org
 help / color / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: "Matthew Rosato" <mjrosato@linux.ibm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Libvirt Devel" <libvir-list@redhat.com>,
	"Kirti Wankhede" <kwankhede@nvidia.com>,
	"Erik Skultety" <eskultet@redhat.com>,
	"Pavel Hrdina" <phrdina@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Sylvain Bauza" <sbauza@redhat.com>,
	"Christophe de Dinechin" <dinechin@redhat.com>,
	"Tony Krowiak" <akrowiak@linux.ibm.com>
Subject: Re: mdevctl: A shoestring mediated device management and persistence utility
Date: Thu, 27 Jun 2019 15:15:02 -0600
Message-ID: <20190627151502.2ae5314f@x1.home> (raw)
In-Reply-To: <20190627093832.064a346f@x1.home>

On Thu, 27 Jun 2019 09:38:32 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> > On 6/27/19 8:26 AM, Cornelia Huck wrote:  
> > > 
> > > {
> > >   "foo": "1",
> > >   "bar": "42",
> > >   "baz": {
> > >     "depends": ["foo", "bar"],
> > >     "value": "plahh"
> > >   }
> > > }
> > > 
> > > Something like that?  
> 
> I'm not sure yet.  I think we need to look at what's feasible (and
> easy) with jq.  Thanks,

I think it's not too much trouble to remove and insert into arrays, so
what if we were to define the config as:

{
  "mdev_type":"vendor-type",
  "start":"auto",
  "attrs": [
      {"attrX":["Xvalue1","Xvalue2"]},
      {"dir/attrY": "Yvalue1"},
      {"attrX": "Xvalue3"}
    ]
}

"attr" here would define sysfs attributes under the device.  The array
would be processed in order, so in the above example we'd do the
following:

 1. echo Xvalue1 > attrX
 2. echo Xvalue2 > attrX
 3. echo Yvalue1 > dir/attrY
 4. echo Xvalue3 > attrX

When starting the device mdevctl would simply walk the array, if the
attribute key exists write the value(s).  If a write fails or the
attribute doesn't exist, remove the device and report error.

I think it's easiest with jq to manipulate arrays by removing and
inserting by index.  Also if we end up with something like above, it's
ambiguous if we reference the "attrX" key.  So perhaps we add the
following options to the modify command:

--addattr=ATTRIBUTE --delattr --index=INDEX --value=VALUE1[,VALUE2]

We could handle it like a stack, so if --index is not supplied, add to
the end or remove from the end.  If --index is provided, delete that
index or add the attribute at that index.  So if you had the above and
wanted to remove Xvalue1 but keep the ordering, you'd do:

--delattr --index=0
--addattr --index=0 --value=Xvalue2

Which should results in:

  "attrs": [
      {"attrX": "Xvalue2"},
      {"dir/attrY": "Yvalue1"},
      {"attrX": "Xvalue3"}
    ]

If we want to modify a running device, I'm thinking we probably want a
new command and options --attr=ATTRIBUTE --value=VALUE might suffice.

Do we need to support something like this for the 'start' command or
should we leave that for simple devices and require a sequence of:

# mdevctl define ...
# mdevctl modify --addattr...
...
# mdevctl start
# mdevctl undefine

This is effectively the long way to get a transient device.  Otherwise
we'd need to figure out how to have --attr --value appear multiple
times on the start command line.  Thanks,

Alex

  parent reply index

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 23:20 Alex Williamson
2019-05-24 10:11 ` Cornelia Huck
2019-05-24 14:43   ` Alex Williamson
2019-06-07 16:06   ` Halil Pasic
2019-06-11 19:45     ` Cornelia Huck
2019-06-11 20:28       ` Alex Williamson
2019-06-12  7:14         ` Cornelia Huck
2019-06-12 15:54           ` Halil Pasic
2019-06-13 10:02             ` Cornelia Huck
2019-06-12 15:07       ` Halil Pasic
2019-06-13 16:17 ` Christophe de Dinechin
2019-06-13 16:35   ` Alex Williamson
2019-06-14  9:54     ` [libvirt] " Christophe de Dinechin
2019-06-14 14:23       ` Alex Williamson
2019-06-14 15:06         ` Christophe de Dinechin
2019-06-14 16:04           ` Alex Williamson
2019-06-17 16:03             ` Cornelia Huck
2019-06-17 14:00 ` Daniel P. Berrangé
2019-06-17 14:54   ` Alex Williamson
2019-06-17 15:10     ` Daniel P. Berrangé
2019-06-17 17:05       ` Alex Williamson
2019-06-18  8:44         ` Daniel P. Berrangé
2019-06-18 11:01         ` Cornelia Huck
     [not found]           ` <CALOCmukPWiXiM+mN0hCTvSwfdHy5UdERU8WnvOXiBrMQ9tH3VA@mail.gmail.com>
2019-06-18 22:12             ` Alex Williamson
2019-06-19  7:28               ` Daniel P. Berrangé
2019-06-19  9:46                 ` Cornelia Huck
2019-06-19 18:46                   ` Alex Williamson
2019-06-20  8:24                     ` Daniel P. Berrangé
     [not found]               ` <CALOCmu=6Xmw-_-SVXujCEcgPY2CQiBQKgfUMJ45WnZ_9XORyUw@mail.gmail.com>
2019-06-19  9:57                 ` Cornelia Huck
2019-06-19 19:53                 ` Alex Williamson
2019-06-25 22:52 ` Alex Williamson
2019-06-26  9:58   ` Cornelia Huck
2019-06-26 14:37     ` Alex Williamson
2019-06-27  1:53       ` Alex Williamson
2019-06-27 12:26         ` Cornelia Huck
2019-06-27 15:00           ` Matthew Rosato
2019-06-27 15:38             ` Alex Williamson
2019-06-27 16:13               ` Matthew Rosato
2019-06-27 21:15               ` Alex Williamson [this message]
2019-06-28  1:57                 ` Alex Williamson
2019-06-28  9:06                   ` Cornelia Huck
2019-06-28 14:01                     ` Matthew Rosato
2019-06-28 17:05                     ` Alex Williamson
2019-07-01  8:20                       ` Cornelia Huck
2019-07-01 14:40                         ` Alex Williamson
2019-07-01 17:13                           ` Cornelia Huck

Reply instructions:

You may reply publically 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=20190627151502.2ae5314f@x1.home \
    --to=alex.williamson@redhat.com \
    --cc=akrowiak@linux.ibm.com \
    --cc=berrange@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=dinechin@redhat.com \
    --cc=eskultet@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=libvir-list@redhat.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=phrdina@redhat.com \
    --cc=sbauza@redhat.com \
    /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

KVM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kvm/0 kvm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kvm kvm/ https://lore.kernel.org/kvm \
		kvm@vger.kernel.org
	public-inbox-index kvm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.kvm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git