Re: EXPORT SYMBOL for alloc_vm_area

[Nick Logan <nick_logan@symantec.com>]

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