From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Cc: virtualization
<virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: [PATCH 1/3] virtio interface
Date: Tue, 25 Sep 2007 00:18:12 +0200 [thread overview]
Message-ID: <200709250018.12705.arnd@arndb.de> (raw)
In-Reply-To: <1190625256.27805.201.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Monday 24 September 2007, 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.
Hi Rusty,
Thanks for your update, as you can imagine, I'm much happier with
this version ;-)
> +
> +struct virtio_bus {
> + struct bus_type bus;
> + struct device dev;
> +};
> +
> +static struct virtio_bus virtio_bus = {
> + .bus = {
> + .name = "virtio",
> + .match = virtio_dev_match,
> + .dev_attrs = virtio_dev_attrs,
> + },
> + .dev = {
> + /* Can override this if you have a real bus behind it. */
> + .parent = NULL,
> + .bus_id = "virtio",
> + }
> +};
This is a pattern I've seen a few times before, but could never understand
what it's good for. What is your reason for defining a new data structure
that is used only once, instead of just
static struct bus_type virtio_bus_type;
static struct device virtio_root_dev;
Also, I would not mix the two in a single source file. Instead, I think
every driver that can provide virtio devices (pci, lguest, ...) should
be responsible for setting the parent appropriately.
> +#ifndef _LINUX_VIRTIO_CONFIG_H
> +#define _LINUX_VIRTIO_CONFIG_H
> +/* Virtio devices use a standardized configuration space to define their
> + * features and pass configuration information, but each implementation can
> + * store and access that space differently. */
> +#include <linux/types.h>
> +
> +/* Status byte for guest to report progress, and synchronize config. */
> +/* We have seen device and processed generic fields (VIRTIO_CONFIG_F_VIRTIO) */
> +#define VIRTIO_CONFIG_S_ACKNOWLEDGE 1
> +/* We have found a driver for the device. */
> +#define VIRTIO_CONFIG_S_DRIVER 2
> +/* Driver has used its parts of the config, and is happy */
> +#define VIRTIO_CONFIG_S_DRIVER_OK 4
> +/* We've given up on this device. */
> +#define VIRTIO_CONFIG_S_FAILED 0x80
> +
> +/* Feature byte (actually 7 bits availabe): */
> +/* Requirements/features of the virtio implementation. */
> +#define VIRTIO_CONFIG_F_VIRTIO 1
> +/* Requirements/features of the virtqueue (may have more than one). */
> +#define VIRTIO_CONFIG_F_VIRTQUEUE 2
> +
> +#ifdef __KERNEL__
> +struct virtio_device;
> +
> +/**
> + * virtio_config_ops - operations for configuring a virtio device
> + * @find: search for the next configuration field of the given type.
> + * vdev: the virtio_device
> + * type: the feature type
> + * len: the (returned) length of the field if found.
> + * Returns a token if found, or NULL. Never returnes the same field twice
> + * (ie. it's used up).
> + * @get: read the value of a configuration field after find().
> + * vdev: the virtio_device
> + * token: the token returned from find().
> + * buf: the buffer to write the field value into.
> + * len: the length of the buffer (given by find()).
> + * Note that contents are conventionally little-endian.
> + * @set: write the value of a configuration field after find().
> + * vdev: the virtio_device
> + * token: the token returned from find().
> + * buf: the buffer to read the field value from.
> + * len: the length of the buffer (given by find()).
> + * Note that contents are conventionally little-endian.
> + * @get_status: read the status byte
> + * vdev: the virtio_device
> + * Returns the status byte
> + * @set_status: write the status byte
> + * vdev: the virtio_device
> + * status: the new status byte
> + * @find_vq: find the first VIRTIO_CONFIG_F_VIRTQUEUE and create a virtqueue.
> + * vdev: the virtio_device
> + * callback: the virqtueue callback
> + * Returns the new virtqueue or ERR_PTR().
> + * @del_vq: free a virtqueue found by find_vq().
> + */
> +struct virtio_config_ops
> +{
> + void *(*find)(struct virtio_device *vdev, u8 type, unsigned *len);
> + void (*get)(struct virtio_device *vdev, void *token,
> + void *buf, unsigned len);
> + void (*set)(struct virtio_device *vdev, void *token,
> + const void *buf, unsigned len);
> + u8 (*get_status)(struct virtio_device *vdev);
> + void (*set_status)(struct virtio_device *vdev, u8 status);
> + struct virtqueue *(*find_vq)(struct virtio_device *vdev,
> + bool (*callback)(struct virtqueue *));
> + void (*del_vq)(struct virtqueue *vq);
> +};
The configuration logic looks more complicated than it should be.
Maybe more of this can be done using data structure definitions instead
of dynamic callback. E.g. the virtqueues of a given device can be
listed as members of the struct virtio_device.
> +/**
> + * virtio_config_val - get a single virtio config and mark it used.
> + * @config: the virtio config space
> + * @type: the type to search for.
> + * @val: a pointer to the value to fill in.
> + *
> + * Once used, the config type is marked with VIRTIO_CONFIG_F_USED so it can't
> + * be found again. This version does endian conversion. */
> +#define virtio_config_val(vdev, type, v) ({ \
> + int _err = __virtio_config_val((vdev),(type),(v),sizeof(*(v))); \
> + \
> + BUILD_BUG_ON(sizeof(*(v)) != 1 && sizeof(*(v)) != 2 \
> + && sizeof(*(v)) != 4 && sizeof(*(v)) != 8); \
> + if (!_err) { \
> + switch (sizeof(*(v))) { \
> + case 2: le16_to_cpus(v); break; \
> + case 4: le32_to_cpus(v); break; \
> + case 8: le64_to_cpus(v); break; \
> + } \
> + } \
> + _err; \
> +})
Especially the macro looks like something better avoided...
Arnd <><
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
next prev parent reply other threads:[~2007-09-24 22:18 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-24 9:13 [PATCH 0/3] virtio implementation (draft VI) Rusty Russell
[not found] ` <1190625194.27805.199.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-09-24 9:14 ` [PATCH 1/3] virtio interface Rusty Russell
[not found] ` <1190625256.27805.201.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-09-24 9:15 ` [PATCH 2/3] virtio ring implementation Rusty Russell
2007-09-24 9:16 ` [PATCH 3/3] virtio module alias support Rusty Russell
[not found] ` <1190625307.27805.203.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-09-24 9:16 ` Rusty Russell
[not found] ` <1190625394.27805.206.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-09-24 16:02 ` Greg KH
2007-09-25 0:50 ` Rusty Russell
[not found] ` <20070924160221.GB5846-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2007-09-25 0:50 ` Rusty Russell
2007-09-25 1:57 ` Greg KH
[not found] ` <1190681405.27805.243.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-09-25 1:57 ` Greg KH
2007-09-25 2:11 ` Rusty Russell
[not found] ` <20070925015747.GA16011-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2007-09-25 2:11 ` Rusty Russell
2007-09-25 3:10 ` Greg KH
[not found] ` <1190686275.27805.255.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-09-25 3:10 ` Greg KH
2007-09-24 16:02 ` Greg KH
2007-09-24 13:44 ` [PATCH 2/3] virtio ring implementation Dor Laor
2007-09-24 23:43 ` [kvm-devel] " Rusty Russell
[not found] ` <46F7BF41.9060705-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-09-24 23:43 ` Rusty Russell
2007-09-25 13:32 ` Rusty Russell
[not found] ` <1190727156.27805.332.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-09-25 17:15 ` Dor Laor
[not found] ` <46F94243.2000602-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-09-25 23:37 ` Rusty Russell
[not found] ` <1190763475.2227.20.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-09-26 9:08 ` Dor Laor
2007-09-26 9:08 ` [kvm-devel] " Dor Laor
2007-09-25 23:37 ` Rusty Russell
2007-09-25 17:15 ` Dor Laor
2007-09-25 13:32 ` Rusty Russell
2007-09-24 13:44 ` Dor Laor
2007-09-24 22:18 ` Arnd Bergmann [this message]
[not found] ` <200709250018.12705.arnd-r2nGTMty4D4@public.gmane.org>
2007-09-24 23:37 ` [PATCH 1/3] virtio interface Rusty Russell
2007-09-25 6:36 ` [kvm-devel] " Arnd Bergmann
2007-09-25 8:18 ` Cornelia Huck
[not found] ` <1190677058.27805.225.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2007-09-25 6:36 ` Arnd Bergmann
2007-09-25 10:54 ` [kvm-devel] " Rusty Russell
[not found] ` <200709250836.29451.arnd-r2nGTMty4D4@public.gmane.org>
2007-09-25 10:54 ` Rusty Russell
2007-09-25 8:18 ` Cornelia Huck
2007-09-24 23:37 ` [kvm-devel] " Rusty Russell
2007-09-24 9:15 ` [PATCH 2/3] virtio ring implementation Rusty Russell
2007-09-24 22:18 ` [kvm-devel] [PATCH 1/3] virtio interface Arnd Bergmann
2007-09-24 9:14 ` Rusty Russell
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=200709250018.12705.arnd@arndb.de \
--to=arnd-r2ngtmty4d4@public.gmane.org \
--cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.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.