On Wed, 28 Sep 2011 16:18:07 +0100, "Daniel P. Berrange" <berra...@redhat.com>
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.
-aneesh
