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

[Daniel P. Berrange]

On Thu, Sep 29, 2011 at 08:52:14PM +0530, Aneesh Kumar K.V wrote:
> On Wed, 28 Sep 2011 16:18:07 +0100, "Daniel P. Berrange" <address@hidden> 
> wrote:
> > 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.
> > 
> 
> Will you not be able to have well defined mount tags, that map these
> directories. I guess we don't want to claim 255 bytes out of config
> space for mount tag. That is one of the reason it is limited to 32
> bytes.

The reason for using paths instead of symbolic names in the
mount tag is because the guest code does not know what paths it
might be asked to mount at runtime. Symbolic names in the mount
tags are only useful if the guest can be told ahead of time about
a finite set of tag -> path mappings, which is not a reasonable
assumption in general.

Regards,
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 :|