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

[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!

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.