summaryrefslogtreecommitdiffstats
path: root/include/asm-xtensa/uaccess.h
diff options
context:
space:
mode:
authorRusty Russell <rusty@rustcorp.com.au>2008-05-02 21:50:50 -0500
committerRusty Russell <rusty@rustcorp.com.au>2008-05-02 21:50:50 +1000
commitc45a6816c19dee67b8f725e6646d428901a6dc24 (patch)
tree096e3263fd14e140685bcc3082394ff15f5aeddb /include/asm-xtensa/uaccess.h
parent72e61eb40b55dd57031ec5971e810649f82b0259 (diff)
downloadblackbird-op-linux-c45a6816c19dee67b8f725e6646d428901a6dc24.tar.gz
blackbird-op-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 'include/asm-xtensa/uaccess.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud