[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [kvm-devel] [PATCH RFC 1/3] virtio infrastructure
Rusty Russell wrote: > This attempts to implement a "virtual I/O" layer which should allow > common drivers to be efficiently used across most virtual I/O > mechanisms. It will no-doubt need further enhancement. > > The details of probing the device are left to hypervisor-specific > code: it simple constructs the "struct virtio_device" and hands it to > the probe function (eg. virtnet_probe() or virtblk_probe()). > > The virtio drivers add and detach input and output buffers; as the > buffers are used up their associated "used" pointers are filled in. > > Good stuff. > +/** > + * virtio_ops - virtio abstraction layer > + * @add_outbuf: prepare to send data to the other end: > + * vdev: the virtio_device > + * sg: the description of the buffer(s). > + * num: the size of the sg array. > + * used: the length sent (set once sending is done). > + * Returns an identifier or an error. > + * @add_inbuf: prepare to receive data from the other end: > + * vdev: the virtio_device > + * sg: the description of the buffer(s). > + * num: the size of the sg array. > + * used: the length sent (set once data received). > + * Returns an identifier or an error (eg. -ENOSPC). > Instead of 'used', how about a completion callback (with associated data pointer)? A new helper, virtio_complete(), would call the callback for all completed requests. It would eliminate all the tedious scanning used to match the identifier. It would also be nice to support a bit of non-buffer data, like a set of bitflags. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |