qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] VirtIO 9p mount_tag (bogus?) limit of 32 bytes


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] VirtIO 9p mount_tag (bogus?) limit of 32 bytes
Date: Wed, 28 Sep 2011 16:18:07 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Sep 28, 2011 at 05:22:06PM +0530, Harsh Bora wrote:
> On 09/22/2011 11:12 PM, Daniel P. Berrange wrote:
> >I've noticed that if you use a virtio 9p filesystem with a mount_tag
> >property value that is longer than 32 bytes, it gets silently truncated.
> >
> >In virtio-9p-device.c
> >
> >     len = strlen(conf->tag);
> >     if (len>  MAX_TAG_LEN) {
> >         len = MAX_TAG_LEN;
> 
> I think its better to return here with a failure message saying
> mount_tag too long. IIUC, The 32 byte limit has been kept because of
> understanding that mount_tag is a device name in guest (and not a
> path location).

While I appreciate the fact that 'mount_tag' is not required to be
a path name, so you can allow symbolic naming for exports, in some
use cases it is important / significantly simpler to be able to just
set a path name. I don't think we should mandate symbolic naming,
or path based naming - we should just allow users to choose which
best suits their needs.

For example, I am building appliances which have multiple 9p devices
exported to the guest. These 9p filesystems are all mounted by the
'init' process in the initrd. If I'm forced to use symbolic naming
for devices, it means I need to create a custom initrd for every
appliance configuration I have (many many many of them), with the
init process knowing how to map from symbolic names back to the
mount paths I actually want. If I can just use a path for the
mount_tag, then one single initrd can be used for all my appliances.

So I really would like 'mount_tag' to be significantly larger upto
at least 255 bytes, or more.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]