qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v11 0/8] Shared Library Module Support


From: Fam Zheng
Subject: Re: [Qemu-devel] [PATCH v11 0/8] Shared Library Module Support
Date: Thu, 26 Sep 2013 21:26:25 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, 09/17 16:54, Fam Zheng wrote:
> This series implements feature of shared object building as described in:
> 
> http://wiki.qemu.org/Features/Modules
> 
> The main idea behind modules is to isolate dependencies on third party
> libraries from qemu executables, such as libglusterfs or librbd, so that the
> end users can install core qemu package with fewer dependencies.  And only for
> those who want to use particular modules, need they install qemu-foo
> sub-package, which in turn requires libbar and libbiz packages.
> 
> It's implemented in three steps:
> 
> 1. The first patches fix current build system to correctly handle nested
>    variables and object specific options:
> 
>     [01/08] ui/Makefile.objs: delete unnecessary cocoa.o dependency
>     [02/08] make.rule: fix $(obj) to a real relative path
>     [03/08] rule.mak: allow per object cflags and libs
> 
> 2. The Makefile changes adds necessary options and rules to build DSO objects:
> 
>     [04/08] build-sys: introduce common-obj-m and block-obj-m for DSO
> 
> 3. The next patch adds code to load modules from installed directory:
> 
>     [05/08] module: implement module loading
> 
> A few more changes are following to complete it:
> 
>     [06/08] Makefile: install modules with "make install"
>     [07/08] .gitignore: ignore module related files (dll, so, mo)
> 
> In the end of series, the block drivers are converted:
> 
>     [08/08] block: convert block drivers linked with libs to modules
> 

Ping?

> v11:
>     [04] Link DSO with  -Wl,--enable-new-dtags -Wl,-rpath,'$$ORIGIN' (Richard)

I don't fully understand the portability issue with this flag yet, is this OK
to keep or should be dropped? Any opinions?

Thanks,
Fam

>     [05] Reuse module_init_type in module_load, no separate load type enums.
>          Separate list of modules by type. It's simply list of built modules
>          now. No whitelist option in configure.
>          Support multiple module_init() in single module.
> 
[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]