On Sat, 2007-09-22 at 12:01 +0200, Arnd Bergmann wrote:
On Saturday 22 September 2007, Rusty Russell wrote:
But now each virtio device has two struct devices, not one. And
you've made up a fictional bus to do it.
Yet for PCI systems, it really is a PCI device; exposing a second bus to
Rusty Russell wrote:
On Sat, 2007-09-22 at 12:01 +0200, Arnd Bergmann wrote:
On Saturday 22 September 2007, Rusty Russell wrote:
But now each virtio device has two struct devices, not one. And
you've made up a fictional bus to do it.
Yet for PCI systems, it really is a PCI device;
On Thursday 20 September 2007, Rusty Russell wrote:
+ * virtio_driver - operations for a virtio I/O driver
+ * @name: the name of the driver (KBUILD_MODNAME).
+ * @owner: the module which contains these routines (ie. THIS_MODULE).
+ * @id_table: the ids (we re-use PCI ids) serviced by this
On Fri, 2007-09-21 at 14:05 +0200, Arnd Bergmann wrote:
On Thursday 20 September 2007, Rusty Russell wrote:
+int register_virtio_driver(struct virtio_driver *drv);
+void unregister_virtio_driver(struct virtio_driver *drv);
+
+/* The particular virtio backend supplies these. */
+struct
On Friday 21 September 2007, Rusty Russell wrote:
Hmm, I guess we could have a PCI driver which claims all VIRTIO vendor
devices.
yes, that was the idea.
Then it can call virtio_find_driver() (?) at the top of its
probe function to find if there's a matching virtio driver.
This PCI
Rusty Russell wrote:
(Changes:
- renamed sync to kick as Dor suggested
- added new_vq and free_vq hooks to create virtqueues
- define a simple virtio driver, which uses PCI ids
- provide register/unregister_virtio_driver hooks)
This attempts to implement a virtual I/O layer which
