| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [Xen-API] [PATCH 2 of 4] xc: split xc non-upstream bindi
On 18/11/10 15:35, Ian Campbell wrote:
Absolutely, I think the XIU stuff is really very useful indeed. I think
it even has the potential for wider usefulness than just XCP.
Addressing this is next on my list so my plan is only half baked (if
that!) but I think the hooks necessary to support an injection
infrastructure of this type could be integrated into libxc without too
much pain. Doing this would allow xl, libvirt etc to also use the XIU
functionality for testing which I think would be really cool.
I've several possible approaches in mind:
* Just whack the hooks and injection layer into libxc itself,
there aren't really that many hook points or that much code in
the injection layer...
* Turn xc_injection_lib.c into a LD_PRELOAD'able library. Requires
moving various, do_{domctl,ioctl,etc} stuff out of line in the
library -- which I think is a good idea anyway.
* Add functionality to libxc to allow it to dlopen a backend (e.g.
pointed to by an envvar) containing the hook implementation with
explicit calls to the layer as necessary.
Probably the second two are pretty much equivalent modulo the name of
the environment variable being either LD_PRELOAD or something else.
Initially I think I prefer the dynamic loading approaches to dropping
the injection stuff directly into libxc. In particular the dynamic
options allow the injection layer and XIU backend to live together
whereas the first option effectively has the injection layer in
xen-unstable.hg and the XIU backend possibly somewhere else which
doesn't seem helpful.
The dynamic solution also allows for other injection layers and backends
but I'm not sure how useful that actually is. Perhaps a valgrind
friendly backend or something like that, dunno
I pretty much agree with you, however just a bit of comments.
option 1 is more dynamic than option 2. you can mix and match backend
just setting/unsetting
your XIU environment before any XC call technically. this isn't possible
with LD_PRELOAD, since
it's one shot during the start of your program.
3 is pretty much equivalent to 1 and best technically IMO. it's just a
bit more efforts to do, hence why option 1 is the one available now.
--
Vincent
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home