All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.