18.06.2013 16:19, Michael Tokarev пишет: > 18.06.2013 16:17, Laszlo Ersek wrote: >> On 06/18/13 13:37, Michael Tokarev wrote: >> >>> Next, and this is the most complex part. The build system for >>> modules, and configuring it. I heard there were plans to use >>> something like kbuild system for that, has anything been done >>> in this context? >> >> Sorry for responding separately... Some module/symbol versioning will be >> necessary, as the binding will be delayed until runtime, and users >> *will* mix and match qemu and modules, and get random crashes. AFAIK >> versioning is a good way to avoid that (you would get an error in >> dlopen(), and dlerror() would pinpoint problem). >> >> No idea how to implement this though, except I expect there's no chance >> to do it halfway portably without libtool. > > Well, I think this is trivial really. > > Duding build, we re-#define register_module_init() to have a version > number (or even a build id), for example register_module_init_1_6_0(). > This is a function which each plugin will call inside its constructor. > Being unable to find this symbol in calling qemu it will fail to load.
$ ./x86_64-softmmu/qemu-system-x86_64 -hda http://foo/bar warning: unable to load plugin plugins/block_curl.so: plugins/block_curl.so: undefined symbol: register_module_init_1_6_0 qemu-system-x86_64: -hda http://foo/bar: could not open disk image http://foo/bar: No such file or directory Looks clear enough. Also, we may add version number to the plugin name too. /mjt