diff options
author | Rusty Russell <rusty@rustcorp.com.au> | 2008-05-02 21:50:50 -0500 |
---|---|---|
committer | Rusty Russell <rusty@rustcorp.com.au> | 2008-05-02 21:50:50 +1000 |
commit | c45a6816c19dee67b8f725e6646d428901a6dc24 (patch) | |
tree | 096e3263fd14e140685bcc3082394ff15f5aeddb /samples | |
parent | 72e61eb40b55dd57031ec5971e810649f82b0259 (diff) | |
download | linux-c45a6816c19dee67b8f725e6646d428901a6dc24.tar.gz linux-c45a6816c19dee67b8f725e6646d428901a6dc24.tar.bz2 linux-c45a6816c19dee67b8f725e6646d428901a6dc24.zip |
virtio: explicit advertisement of driver features
A recent proposed feature addition to the virtio block driver revealed
some flaws in the API: in particular, we assume that feature
negotiation is complete once a driver's probe function returns.
There is nothing in the API to require this, however, and even I
didn't notice when it was violated.
So instead, we require the driver to specify what features it supports
in a table, we can then move the feature negotiation into the virtio
core. The intersection of device and driver features are presented in
a new 'features' bitmap in the struct virtio_device.
Note that this highlights the difference between Linux unsigned-long
bitmaps where each unsigned long is in native endian, and a
straight-forward little-endian array of bytes.
Drivers can still remove feature bits in their probe routine if they
really have to.
API changes:
- dev->config->feature() no longer gets and acks a feature.
- drivers should advertise their features in the 'feature_table' field
- use virtio_has_feature() for extra sanity when checking feature bits
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Diffstat (limited to 'samples')
0 files changed, 0 insertions, 0 deletions