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, 03 Jul 2013 23:06:22 +0000 [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
WARNING: multiple messages have this Message-ID (diff)
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: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-02 23:25 RFC: vfio interface for platform devices Yoder Stuart-B08248
2013-07-02 23:25 ` Yoder Stuart-B08248
2013-07-03 1:07 ` Alexander Graf
2013-07-03 1:07 ` Alexander Graf
2013-07-03 1:07 ` Alexander Graf
2013-07-03 18:51 ` Scott Wood
2013-07-03 18:51 ` Scott Wood
2013-07-03 18:51 ` Scott Wood
2013-07-03 19:08 ` Yoder Stuart-B08248
2013-07-03 19:08 ` Yoder Stuart-B08248
2013-07-03 3:07 ` Alex Williamson
2013-07-03 3:07 ` Alex Williamson
2013-07-03 10:44 ` Antonios Motakis
2013-07-03 10:44 ` Antonios Motakis
2013-07-03 10:44 ` Antonios Motakis
2013-07-03 19:23 ` Yoder Stuart-B08248
2013-07-03 19:23 ` Yoder Stuart-B08248
2013-07-03 19:23 ` Yoder Stuart-B08248
2013-07-03 17:20 ` Yoder Stuart-B08248
2013-07-03 17:20 ` Yoder Stuart-B08248
2013-07-03 21:40 ` RFC: vfio interface for platform devices (v2) Yoder Stuart-B08248
2013-07-03 21:40 ` Yoder Stuart-B08248
2013-07-03 22:53 ` Alex Williamson
2013-07-03 22:53 ` Alex Williamson
2013-07-03 22:53 ` Alex Williamson
2013-07-03 23:06 ` Scott Wood
2013-07-03 23:06 ` Scott Wood [this message]
2013-07-03 23:06 ` Scott Wood
2013-07-16 21:57 ` Yoder Stuart-B08248
2013-07-16 21:57 ` Yoder Stuart-B08248
2013-07-16 21:57 ` Yoder Stuart-B08248
2013-07-04 14:44 ` Mario Smarduch
2013-07-04 14:44 ` Mario Smarduch
2013-07-04 14:44 ` Mario Smarduch
2013-07-04 14:47 ` Alexander Graf
2013-07-04 14:47 ` Alexander Graf
2013-07-04 14:47 ` Alexander Graf
2013-07-16 15:25 ` Yoder Stuart-B08248
2013-07-03 22:31 ` RFC: vfio interface for platform devices Scott Wood
2013-07-03 22:31 ` Scott Wood
2013-07-03 22:31 ` Scott Wood
2013-07-16 21:51 ` Yoder Stuart-B08248
2013-07-16 22:01 ` Scott Wood
2013-07-16 22:01 ` Scott Wood
2013-07-16 22:41 ` Yoder Stuart-B08248
2013-07-16 22:50 ` Scott Wood
2013-07-16 22:50 ` Scott Wood
2013-07-16 22:50 ` Scott Wood
2013-07-16 22:01 ` Scott Wood
2013-07-16 21:51 ` Yoder Stuart-B08248
-- strict thread matches above, loose matches on Subject: below --
2013-07-03 21:40 RFC: vfio interface for platform devices (v2) 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 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.