[Top][All Lists]

[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: Aneesh Kumar K.V
Subject: Re: [Qemu-devel] VirtIO 9p mount_tag (bogus?) limit of 32 bytes
Date: Thu, 29 Sep 2011 20:52:14 +0530
User-agent: Notmuch/0.9_rc1 (http://notmuchmail.org) Emacs/23.2.1 (x86_64-pc-linux-gnu)

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


reply via email to

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