[libvirt] [PATCH] Added new attribute exportfs_type to filesystem element

Harsh Bora harsh at linux.vnet.ibm.com
Thu Oct 7 06:22:50 UTC 2010


Hi Daniel,
Makes sense, agreed.
However, did you get a chance to review the security_model patch?

https://www.redhat.com/archives/libvir-list/2010-September/msg00435.html

On 10/06/2010 09:59 PM, Daniel P. Berrange wrote:
> On Wed, Oct 06, 2010 at 06:22:29PM +0200, Daniel Veillard wrote:
>> On Thu, Sep 30, 2010 at 10:30:10PM +0530, Harsh Prateek Bora wrote:
>>> This patch introduces a new attribute export_fs to the filesystem
>>> element which specifies the type of export. Currently only 'local'
>>> type of exported filesystem is supported. More types like NFS, clusterFS, etc.
>>> can be added later as required.
>>>
>>> Note: This patch is based on the following two patches:
>>> 1) Daniel's patch to support 9pfs:
>>> https://www.redhat.com/archives/libvir-list/2010-September/msg00358.html
>>> 2) Another related patch to support 'security_model' attribute:
>>> https://www.redhat.com/archives/libvir-list/2010-September/msg00435.html
>>>
>>> Signed-off-by: Harsh Prateek Bora<harsh at linux.vnet.ibm.com>
>>
>>    Okay, I don't understand what's the point of adding that attribute
>> with only one possible value and systematically generated.
>>    I think it's better to propose this when there is an actual use
>> case for the attribute, then it will be easier to say if this is the
>> right construct to add or not.
>
> I agree and in fact think this extra attribute is almost certainly the
> wrong approach. The existing<filesystem type='....'>  attribute should
> be sufficient for our needs. When QEMU supports FS backends which
> are not 'local', then we will likely add extra values for type='...'
> to cope with them. So lets just wait until QEMU actually supports some
> non-local modes.
>
> Regards,
> Daniel




More information about the libvir-list mailing list