From: Scott Wood <scottwood@freescale.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Yoder Stuart-B08248 <B08248@freescale.com>,
Alexander Graf <agraf@suse.de>,
Wood Scott-B07421 <B07421@freescale.com>,
Bhushan Bharat-R65777 <R65777@freescale.com>,
Sethi Varun-B16395 <B16395@freescale.com>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
Antonios Motakis <a.motakis@virtualopensystems.com>,
"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: RFC: vfio interface for platform devices (v2)
Date: Wed, 3 Jul 2013 18:06:22 -0500 [thread overview]
Message-ID: <1372892782.8183.158@snotra> (raw)
In-Reply-To: <1372891989.2883.248.camel@ul30vt.home> (from alex.williamson@redhat.com on Wed Jul 3 17:53:09 2013)
On 07/03/2013 05:53:09 PM, Alex Williamson wrote:
> Seems like it should work. My only API concern with this model of
> appending structs is that a user needs to know the size of each struct
> even if they don't otherwise care about it in order to step over it.
In that case, it might be better to make the struct grow linearly
rather than with options, and just have a version number on the struct
indicating how far the caller thinks struct has grown. The kernel
could respond back with a lower version to reflect that it only filled
in the fields it knows about. Flags could still be used to indicate
which portions of the struct are relevant, but not the physical layout
of the struct.
> In some cases, like the path, the size is variable and the user needs
> to
> look into it.
For things like path, maybe the caller should just pass in a string
buffer that is separate from the struct buffer?
-Scott
next prev parent reply other threads:[~2013-07-03 23:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-03 21:40 RFC: vfio interface for platform devices (v2) Yoder Stuart-B08248
2013-07-03 22:53 ` Alex Williamson
2013-07-03 23:06 ` Scott Wood [this message]
2013-07-16 21:57 ` Yoder Stuart-B08248
2013-07-04 14:44 ` Mario Smarduch
2013-07-04 14:47 ` Alexander Graf
2013-07-16 15:25 ` Yoder Stuart-B08248
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=1372892782.8183.158@snotra \
--to=scottwood@freescale.com \
--cc=B07421@freescale.com \
--cc=B08248@freescale.com \
--cc=B16395@freescale.com \
--cc=R65777@freescale.com \
--cc=a.motakis@virtualopensystems.com \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=virtualization@lists.linux-foundation.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