From: Arnd Bergmann <arnd@arndb.de>
To: Ira Snyder <iws@ovro.caltech.edu>
Cc: linuxppc-dev@ozlabs.org, netdev@vger.kernel.org,
Rusty Russell <rusty@rustcorp.com.au>,
linux-kernel@vger.kernel.org,
Jan-Bernd Themann <THEMANN@de.ibm.com>
Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
Date: Fri, 27 Feb 2009 00:44:52 +0100 [thread overview]
Message-ID: <200902270044.53683.arnd@arndb.de> (raw)
In-Reply-To: <20090226231742.GB19959@ovro.caltech.edu>
On Friday 27 February 2009, Ira Snyder wrote:
> On Thu, Feb 26, 2009 at 11:34:33PM +0100, Arnd Bergmann wrote:
> > I guess the best option for doing it in Linux then would be to have
> > a board control driver (not sure if this already exists) that exports
> > high-level functions to set up the inbound and outbound windows.
> >
>
> Nothing like it exists. The OF device tree doesn't even describe these
> registers. The code in arch/powerpc/sysdev/fsl_pci.c uses some registers
> near these, but it gets their address by masking the low bits off the
> addresses from the device tree and adding the offsets of the new
> registers. Nasty.
>
> I'll do this for now:
> 1) Get the message unit registers from my device tree
> 2) Encapsulate all use of get_immrbase() to a single function
>
> That way it could be easily replaced in the future when something more
> suitable comes along.
Ok. However, I don't expect this to get fixed magically. Ideally,
you would start a new file for the board control in arch/powerpc/sysdev
and export the function from there, otherwise you do it the way you
suggested.
Then we can tell the fsl_pci and other people to use the same
method and source file to access the board control.
>
> I didn't think about this at all. This driver could be used to boot a
> (guest) system over NFS, so in that case there isn't a userspace running
> yet, to allow configuration. This is essentially my use case, though I
> haven't implemented it yet.
>
> Also, I hate designing user interfaces :) Any concrete suggestions on
> design would be most welcome.
Don't worry about it for now, just put all the hardcoded virtio_net
specific stuff into a file separate from the hardware specific
files so that we have a nice kernel level abstraction to build a
user abstraction on top of.
Arnd <><
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Ira Snyder <iws@ovro.caltech.edu>
Cc: linux-kernel@vger.kernel.org,
Rusty Russell <rusty@rustcorp.com.au>,
Jan-Bernd Themann <THEMANN@de.ibm.com>,
linuxppc-dev@ozlabs.org, netdev@vger.kernel.org
Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
Date: Fri, 27 Feb 2009 00:44:52 +0100 [thread overview]
Message-ID: <200902270044.53683.arnd@arndb.de> (raw)
In-Reply-To: <20090226231742.GB19959@ovro.caltech.edu>
On Friday 27 February 2009, Ira Snyder wrote:
> On Thu, Feb 26, 2009 at 11:34:33PM +0100, Arnd Bergmann wrote:
> > I guess the best option for doing it in Linux then would be to have
> > a board control driver (not sure if this already exists) that exports
> > high-level functions to set up the inbound and outbound windows.
> >
>
> Nothing like it exists. The OF device tree doesn't even describe these
> registers. The code in arch/powerpc/sysdev/fsl_pci.c uses some registers
> near these, but it gets their address by masking the low bits off the
> addresses from the device tree and adding the offsets of the new
> registers. Nasty.
>
> I'll do this for now:
> 1) Get the message unit registers from my device tree
> 2) Encapsulate all use of get_immrbase() to a single function
>
> That way it could be easily replaced in the future when something more
> suitable comes along.
Ok. However, I don't expect this to get fixed magically. Ideally,
you would start a new file for the board control in arch/powerpc/sysdev
and export the function from there, otherwise you do it the way you
suggested.
Then we can tell the fsl_pci and other people to use the same
method and source file to access the board control.
>
> I didn't think about this at all. This driver could be used to boot a
> (guest) system over NFS, so in that case there isn't a userspace running
> yet, to allow configuration. This is essentially my use case, though I
> haven't implemented it yet.
>
> Also, I hate designing user interfaces :) Any concrete suggestions on
> design would be most welcome.
Don't worry about it for now, just put all the hardcoded virtio_net
specific stuff into a file separate from the hardware specific
files so that we have a nice kernel level abstraction to build a
user abstraction on top of.
Arnd <><
next prev parent reply other threads:[~2009-02-26 23:45 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-24 0:00 [RFC v2] virtio: add virtio-over-PCI driver Ira Snyder
2009-02-24 0:00 ` Ira Snyder
2009-02-26 16:15 ` Arnd Bergmann
2009-02-26 16:15 ` Arnd Bergmann
2009-02-26 16:53 ` Geert Uytterhoeven
2009-02-26 16:53 ` Geert Uytterhoeven
2009-02-26 20:25 ` Ira Snyder
2009-02-26 20:25 ` Ira Snyder
2009-02-26 20:01 ` Ira Snyder
2009-02-26 20:01 ` Ira Snyder
2009-02-26 20:37 ` Arnd Bergmann
2009-02-26 20:37 ` Arnd Bergmann
2009-02-26 21:49 ` Ira Snyder
2009-02-26 21:49 ` Ira Snyder
2009-02-26 22:34 ` Arnd Bergmann
2009-02-26 22:34 ` Arnd Bergmann
2009-02-26 23:17 ` Ira Snyder
2009-02-26 23:17 ` Ira Snyder
2009-02-26 23:44 ` Arnd Bergmann [this message]
2009-02-26 23:44 ` Arnd Bergmann
2009-04-21 6:09 ` Grant Likely
2009-04-21 6:09 ` Grant Likely
2009-04-14 20:28 ` Grant Likely
2009-04-14 20:28 ` Grant Likely
2009-04-14 21:23 ` David Hawkins
2009-04-14 21:23 ` David Hawkins
2009-04-14 21:45 ` Grant Likely
2009-04-14 21:45 ` Grant Likely
2009-04-14 21:52 ` David Hawkins
2009-04-14 21:52 ` David Hawkins
2009-04-14 22:16 ` Grant Likely
2009-04-14 22:16 ` Grant Likely
2009-04-14 22:27 ` David Hawkins
2009-04-14 22:27 ` David Hawkins
2009-04-14 21:53 ` Ira Snyder
2009-04-14 21:53 ` Ira Snyder
2009-06-11 14:22 ` Grant Likely
2009-06-11 14:22 ` Grant Likely
2009-06-11 15:10 ` Ira Snyder
2009-06-11 15:10 ` Ira Snyder
-- strict thread matches above, loose matches on Subject: below --
2011-05-06 12:00 Kushwaha Prabhakar-B32579
2011-05-06 12:00 ` Kushwaha Prabhakar-B32579
2011-05-06 16:06 ` Ira W. Snyder
2011-05-06 16:06 ` Ira W. Snyder
2011-05-07 5:59 ` Kushwaha Prabhakar-B32579
2011-05-07 5:59 ` Kushwaha Prabhakar-B32579
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=200902270044.53683.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=THEMANN@de.ibm.com \
--cc=iws@ovro.caltech.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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.