From: Rusty Russell <rusty@rustcorp.com.au>
To: Avi Kivity <avi@redhat.com>, Rusty Russell <rusty.russell@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Christoffer Dall <c.dall@virtualopensystems.com>,
Alexander Graf <agraf@suse.de>,
kvmarm@lists.cs.columbia.edu, kvm-devel <kvm@vger.kernel.org>
Subject: Re: [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic.
Date: Sat, 01 Sep 2012 22:05:52 +0930 [thread overview]
Message-ID: <873931539z.fsf@rustcorp.com.au> (raw)
In-Reply-To: <5041D3AE.6090804@redhat.com>
Avi Kivity <avi@redhat.com> writes:
>> -Capability: basic
>> +Capability: KVM_CAP_REG_LIST
>> Architectures: arm
>
> all
OK, I guess that's to be true in future. Fixed.
>> Type: vcpu ioctl
>> -Parameters: struct kvm_msr_list (in/out)
>> +Parameters: struct kvm_reg_list (in/out)
>> Returns: 0 on success; -1 on error
>> Errors:
>> - E2BIG: the msr index list is too big to fit in the array specified by
>> - the user.
>> + E2BIG: the reg index list is too big to fit in the array specified by
>> + the user (the number required will be written into n).
>>
>> struct kvm_msr_list {
>> - __u32 nmsrs; /* number of msrs in entries */
>> - __u32 indices[0];
>> + __u64 n; /* number of registers in reg[] */
>> + __u64 reg[0];
>> };
>>
>
> People complain that this interface is hard to use.
>
> How about supplying the address of the array (in addition to n) so you
> don't have to deal with variable sized arrays, and dropping E2BIG in
> favour of always updating n (n changed to something bigger than you had
> -> reallocate and rerun)
We re-write n anyway, *and* return -E2BIG. Not returning an error is
asking for trouble.
Passing an address in a struct is pretty bad, since it involves
compatibility wrappers. I don't think that is what makes the API hard
to use.
Cheers,
Rusty.
next prev parent reply other threads:[~2012-09-01 12:36 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-28 23:37 [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic Rusty Russell
2012-08-28 23:45 ` [RFC 1/5] KVM: Move KVM_SET_ONE_REG/KVM_GET_ONE_REG to generic code Rusty Russell
2012-09-01 9:11 ` Avi Kivity
2012-09-01 10:18 ` Peter Maydell
2012-09-01 10:44 ` Avi Kivity
2012-08-28 23:46 ` [RFC 2/5] KVM: ARM: use KVM_SET_ONE_REG/KVM_GET_ONE_REG Rusty Russell
2012-08-29 15:10 ` Christoffer Dall
2012-08-28 23:47 ` [RFC 3/5] KVM: Add KVM_VCPU_GET_REG_LIST Rusty Russell
2012-08-29 15:13 ` Christoffer Dall
2012-08-28 23:47 ` [RFC 4/5] KVM: ARM: Use KVM_VCPU_GET_REG_LIST Rusty Russell
2012-08-29 15:14 ` Christoffer Dall
2012-08-28 23:48 ` [RFC 5/5] KVM: ARM: Access all registers via KVM_GET_ONE_REG/KVM_SET_ONE_REG Rusty Russell
2012-08-29 15:29 ` Christoffer Dall
2012-09-01 9:14 ` Avi Kivity
2012-08-29 15:36 ` Peter Maydell
2012-08-29 18:21 ` Rusty Russell
2012-09-01 9:16 ` Avi Kivity
2012-09-01 10:25 ` Peter Maydell
2012-09-01 19:40 ` Christoffer Dall
2012-09-04 13:09 ` Peter Maydell
2012-09-04 14:29 ` Christoffer Dall
2012-09-05 6:37 ` Rusty Russell
2012-08-29 18:16 ` Rusty Russell
2012-08-29 16:30 ` [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic Peter Maydell
2012-08-29 18:39 ` Rusty Russell
2012-09-01 9:21 ` Avi Kivity
2012-09-01 12:35 ` Rusty Russell [this message]
2012-09-03 9:20 ` Avi Kivity
2012-09-03 12:33 ` Rusty Russell
2012-09-03 12:49 ` Peter Maydell
2012-09-04 11:48 ` Avi Kivity
2012-09-04 13:59 ` Alexander Graf
2012-09-06 14:44 ` Avi Kivity
2012-09-05 6:43 ` Rusty Russell
2012-09-01 12:28 ` Rusty Russell
2012-09-01 12:37 ` Rusty Russell
2012-09-04 13:31 ` Peter Maydell
2012-09-05 3:15 ` Alexander Graf
2012-09-05 6:48 ` Rusty Russell
2012-09-05 8:52 ` Peter Maydell
2012-09-06 1:44 ` Rusty Russell
2012-09-06 7:37 ` Peter Maydell
2012-09-06 14:48 ` Avi Kivity
2012-09-06 15:08 ` Alexander Graf
2012-09-06 15:16 ` Avi Kivity
2012-09-06 15:23 ` Peter Maydell
2012-09-06 15:35 ` Avi Kivity
2012-09-06 23:00 ` Rusty Russell
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=873931539z.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=c.dall@virtualopensystems.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=peter.maydell@linaro.org \
--cc=rusty.russell@linaro.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).