From: Anthony Liguori <aliguori@us.ibm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Avi Kivity <avi@qumranet.com>,
Gregory Haskins <gregory.haskins.ml@gmail.com>,
Dor Laor <dor.laor@qumranet.com>,
virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: Use of virtio device IDs
Date: Wed, 07 Nov 2007 11:33:02 -0600 [thread overview]
Message-ID: <4731F6CE.6000205@us.ibm.com> (raw)
In-Reply-To: <200711071709.47192.rusty@rustcorp.com.au>
Rusty Russell wrote:
> On Wednesday 07 November 2007 16:40:13 Avi Kivity wrote:
>
>> Gregory Haskins wrote:
>>
>>> but FWIW: This is a major motivation for the reason that the
>>> IOQ stuff I posted a while back used strings for device identification
>>> instead of a fixed length, centrally managed namespace like PCI
>>> vendor/dev-id. Then you can just name your device something reasonably
>>> unique (e.g. "qumranet::veth", or "ibm-pvirt-clock").
>>>
>> I dislike strings. They make it look as if you have a nice extensible
>> interface, where in reality you have a poorly documented interface which
>> leads to poor interoperability.
>>
>
> Yes, you end up with exactly names like "qumranet::veth"
> and "ibm-pvirt-clock". I would recommend looking very hard at /proc, Open
> Firmware on a modern system, or the Xen store, to see what a lack of
> limitation can do to you :)
>
FWIW, I've switched to using the PCI subsystem vendor/device IDs for
virtio which Rusty suggested. I think this makes even more sense than
using the main vendor/device ID since I do think that we only should use
a single vendor/device ID for all virtio PCI devices and then
differentiate based on the subsystem IDs.
Regards,
Anthony Liguori
>> We will support non-pci for s390, but in order to support Windows and
>> older Linux PCI is necessary.
>>
>
> The aim is that PCI support is clean, but that we're not really tied to PCI.
> I think we're getting closer with the recent config changes.
>
> Cheers,
> Rusty.
>
next prev parent reply other threads:[~2007-11-07 17:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-06 17:16 Use of virtio device IDs Anthony Liguori
2007-11-06 18:49 ` Anthony Liguori
2007-11-07 3:38 ` Gregory Haskins
2007-11-07 5:40 ` Avi Kivity
2007-11-07 6:09 ` Rusty Russell
2007-11-07 6:29 ` Anthony Liguori
2007-11-07 6:29 ` Anthony Liguori
2007-11-07 17:33 ` Anthony Liguori [this message]
2007-11-07 17:33 ` Anthony Liguori
2007-11-07 6:09 ` Rusty Russell
2007-11-07 20:38 ` Gregory Haskins
2007-11-08 6:37 ` Avi Kivity
2007-11-08 6:37 ` Avi Kivity
2007-11-08 9:17 ` Gerd Hoffmann
2007-11-08 9:17 ` Gerd Hoffmann
2007-11-08 16:40 ` Anthony Liguori
2007-11-08 16:40 ` Anthony Liguori
2007-11-13 13:18 ` Gregory Haskins
2007-11-13 13:59 ` Zachary Amsden
2007-11-13 13:59 ` Zachary Amsden
2007-11-13 13:18 ` Gregory Haskins
2007-11-07 20:38 ` Gregory Haskins
2007-11-07 5:40 ` Avi Kivity
2007-11-07 3:38 ` Gregory Haskins
2007-11-06 18:49 ` Anthony Liguori
-- strict thread matches above, loose matches on Subject: below --
2007-11-06 17:16 Anthony Liguori
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=4731F6CE.6000205@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=avi@qumranet.com \
--cc=dor.laor@qumranet.com \
--cc=gregory.haskins.ml@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--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.