From: Christoffer Dall <christoffer.dall@linaro.org>
To: Baptiste Reynal <b.reynal@virtualopensystems.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
"tech@virtualopensystems.com" <tech@virtualopensystems.com>,
Linux IOMMU <iommu@lists.linux-foundation.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [RFC PATCH v5 0/3] vfio: platform: return device properties for a platform device
Date: Mon, 5 Oct 2015 11:53:25 +0200 [thread overview]
Message-ID: <20151005095325.GG9011@cbox> (raw)
In-Reply-To: <CAN9JPjF+gYJaxm1kO5c4Swps4TDKrHxJ3v-NP2D_YzEghkn1DA@mail.gmail.com>
[why are you top-posting?]
On Mon, Oct 05, 2015 at 11:42:38AM +0200, Baptiste Reynal wrote:
> In this patch series we want to wrap an already available kernel
> interface to expose a device property to userspace,
which 'already available kernel interface' is that exactly?
> in order to keep
> the code lighter on the userspace. We need those properties in VFIO as
I'm not sure I agree with your 'need those properties in VFIO' statement
here, can you elaborate?
> VFIO grants the possibility to develop userspace drivers.
>
> The sysfs doesn't seems to be ready for this kind of usage. We can
> only find raw data that require heavy parsing. Here we retrieve
> directly usable data and it can be extended later according to new
> needs (as it is already done with ACPI).
Why couldn't you expose this kind of data through sysfs instead of VFIO
and independently of VFIO? Would that be more wrong/difficult/whatever?
>
> This interface has been developed for VFIO and is currently bound to
> it, though there is no special dependencies with it. We could make it
> more generic, but I can only think of VFIO to use it.
Thanks,
-Christoffer
next prev parent reply other threads:[~2015-10-05 9:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 9:07 [RFC PATCH v5 0/3] vfio: platform: return device properties for a platform device Baptiste Reynal
[not found] ` <1443604077-3155-1-git-send-email-b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
2015-10-02 19:28 ` Alex Williamson
[not found] ` <1443814099.26107.124.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-10-02 20:28 ` Christoffer Dall
2015-10-02 22:53 ` Peter Maydell
2015-10-05 9:37 ` Christoffer Dall
2015-10-05 10:07 ` Peter Maydell
[not found] ` <CAFEAcA_ZGaS__7LPFR_JJEs0=KpDNjYQB_ib2pNDLLp2S0zSMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-05 10:32 ` Christoffer Dall
2015-10-05 10:48 ` Mark Rutland
[not found] ` <CAFEAcA84seKfSh94XFJZxBeBzRd=twj2QaFvjMeDKYhrWQu7Nw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-05 9:42 ` Baptiste Reynal
2015-10-05 9:53 ` Christoffer Dall [this message]
2015-10-05 10:04 ` Baptiste Reynal
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=20151005095325.GG9011@cbox \
--to=christoffer.dall@linaro.org \
--cc=alex.williamson@redhat.com \
--cc=b.reynal@virtualopensystems.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=tech@virtualopensystems.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
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