On 4 April 2018 at 23:41, Stefan Hajnoczi <stefa...@gmail.com> wrote:
> 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 > Thanks Stefan, looking to develop a lizardfs block driver. A process that only involved building a module rather than the entire qemu tree would mike life easier, especially if I could test it on a live system (proxmox cluster). A custom qemu install is not an option for that. -- Lindsay