On Tue, Apr 03, 2018 at 11:30:33AM +0800, Fam Zheng wrote: > On Tue, 04/03 13:17, Lindsay Mathieson wrote: > > On 3 April 2018 at 13:11, Fam Zheng <f...@redhat.com> wrote: > > > > > On Tue, 04/03 12:59, Lindsay Mathieson wrote: > > > > Hi all, was looking at developing a block driver for qemu - have > > > > examined > > > > the drivers at: > > > > > > > > https://github.com/qemu/qemu/tree/master/block > > > > > > > > And it seems straightforward enough. > > > > > > > > One thing that is unclear - all the drivers appear to be compiled > > > directly > > > > into qemu. Is there no way to load them dynamically as .so modules? > > > > > > './configure --enable-modules' will enable building block drivers as .so > > > objects, and they are loaded dynamically. These are in-tree .so modules; > > > out-of-tree modules like in Linux kernel are intentionally forbidden. > > > > > > Fam > > > > > > > > > > > Rats, I take it that means I can't develop a testing block module and load > > it with an pre-existing qemu install. > > No, that's not possible.
Depending on what you are trying to do, you could use the blkdebug, null-co, NBD, or iSCSI drivers to perform your testing. blkdebug does fault injection (e.g. you can test what happens when certain I/O requests fail). null-co is a nop block driver useful for some types of performance testing and it also supports introducing an artificial delays. NBD and iSCSI can be used to forward I/O requests to an external server where you can implement any behavior you want. We can discuss it more if you can explain what you're trying to do. Stefan
signature.asc
Description: PGP signature