xen-devel
[Xen-devel] Re: EXPORT SYMBOL for alloc_vm_area
Jon Mason wrote:
On Wed, Jan 25, 2006 at 04:25:41PM +0200, Muli Ben-Yehuda wrote:
On Wed, Jan 25, 2006 at 11:36:11AM +0000, Nick Logan wrote:
It certainly seems that you need all of the functions in
drivers/xen/util.c, ie alloc_vm_area, free_vm_area, lock_vm_area and
unlock_vm_area to be exported in order build a loadable xen driver. Can
these be added?
These functions are only needed to build the backend drivers as modules.
While this seems like it should be possible, the possibility of removing
the backend while frontends exists is a BAD idea and probably should not
be possible (unless we have an infrastructure similar to one described
by Harry Butterworht).
Just curious, why do you need loadable Xen drivers?
To break Xen in new and interesting ways!
Thanks,
Jon
Some background to my questions. I am currently investigating the port
on the Veritas volume manager and filesystem to the xen architecture.
The logical approach is to use the volume manager in Dom0 and the
filesystem in DomU and this can currently be done using the vbd driver.
However the filesystem in DomU then just sees the volume as a disk
partition and is unable to make use of a number of private functions
supplied by the volume manager to provide the filesystem with additional
functionality and performance. Therefore I am investigating the
implementation of a virtual volume driver that would provide those
private functions in DomU. There is no need for this driver to be
included in the xen source, hence the need for a loadable driver.
Nick
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|