From: "Hans J. Koch" <hjk@hansjkoch.de>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Hans J. Koch" <hjk@hansjkoch.de>,
Andreas Schallenberg <embedded@gmx.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Dominic Eschweiler <eschweiler@fias.uni-frankfurt.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kvm@vger.kernel.org
Subject: Re: UIO: missing resource mapping
Date: Fri, 13 Jul 2012 01:40:11 +0200 [thread overview]
Message-ID: <20120712234011.GE2592@local> (raw)
In-Reply-To: <20120712231632.GC9317@redhat.com>
On Fri, Jul 13, 2012 at 02:16:32AM +0300, Michael S. Tsirkin wrote:
> On Thu, Jul 12, 2012 at 09:44:33PM +0200, Hans J. Koch wrote:
> > > Looking further at the code, I cannot see where the mem fields are
> > > being filled at all.
> > > Which code is supposed to write the struct uio_mem?
> >
> > In my opinion, the driver should. However, Michael's idea is to use
> > /sys/bus/pci/devices/XXXXXresourceX for mapping purposes.
> >
> > That is of course also possible, but obviously it leads to confusion.
> > We already had a long thread about this:
> >
> > http://www.spinics.net/lists/kvm/msg73837.html
> >
> > Michael, can we change the driver to offer all available PCI BARs in the
> > normal UIO way? I'm afraid otherwise we'll have the same discussion over
> > and over again.
> >
> > Thanks,
> > Hans
>
> My concern was people will ask for more and more stuff that pci
> sysfs already has.
> If we do add these is there a way to not duplicate code from pci?
> Export pci_mmap_resource and use it? Or make the uio attributes
> softlinks to pci sysfs somehow?
I understand your concern. Of course I'm also not in favor of duplicating
code, but I don't think there's much overhead. PCI already exports all
information needed by pci_resource_start(dev, bar) and
pci_resource_len(dev, bar). Have a look at other UIO PCI drivers like
uio_cif.c or uio_netx.c to see how it works. It's just a few more lines
of code to loop through all BARs and add the to info->mem[i].
By the way, the current size of the info->mem[] array was exactly made
with PCI in mind...
Thanks,
Hans
next prev parent reply other threads:[~2012-07-12 23:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-12 7:26 UIO: missing resource mapping Andreas Schallenberg
2012-07-12 19:44 ` Hans J. Koch
2012-07-12 23:16 ` Michael S. Tsirkin
2012-07-12 23:40 ` Hans J. Koch [this message]
2012-07-12 23:58 ` Michael S. Tsirkin
2012-07-13 8:09 ` Dominic Eschweiler
2012-07-13 13:22 ` Michael S. Tsirkin
2012-07-13 14:18 ` Hans J. Koch
2012-07-13 14:44 ` Dominic Eschweiler
2012-07-13 14:42 ` Dominic Eschweiler
2012-07-13 18:19 ` Michael S. Tsirkin
2012-07-16 18:16 ` Dominic Eschweiler
2012-07-16 21:58 ` Hans J. Koch
2012-07-18 10:40 ` Dominic Eschweiler
2012-07-18 23:47 ` Hans J. Koch
2012-08-06 11:49 ` Dominic Eschweiler
2012-08-08 22:08 ` Hans J. Koch
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=20120712234011.GE2592@local \
--to=hjk@hansjkoch.de \
--cc=embedded@gmx.net \
--cc=eschweiler@fias.uni-frankfurt.de \
--cc=gregkh@linuxfoundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.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 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.