From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9IfL-0003P2-QY for qemu-devel@nongnu.org; Thu, 29 Sep 2011 11:36:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R9IfK-0003g4-ND for qemu-devel@nongnu.org; Thu, 29 Sep 2011 11:36:51 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:57877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9IfK-0003fm-Hh for qemu-devel@nongnu.org; Thu, 29 Sep 2011 11:36:50 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p8TF1Gce030399 for ; Thu, 29 Sep 2011 11:01:16 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8TFaedB979160 for ; Thu, 29 Sep 2011 11:36:40 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8TFZpRQ013911 for ; Thu, 29 Sep 2011 12:36:39 -0300 From: "Aneesh Kumar K.V" In-Reply-To: <20110928151807.GU21102@redhat.com> References: <20110922174233.GD31504@redhat.com> <4E830A66.50605@linux.vnet.ibm.com> <20110928151807.GU21102@redhat.com> Date: Thu, 29 Sep 2011 20:52:14 +0530 Message-ID: <87fwjfqspl.fsf@skywalker.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] VirtIO 9p mount_tag (bogus?) limit of 32 bytes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , Harsh Bora Cc: qemu-devel@nongnu.org On Wed, 28 Sep 2011 16:18:07 +0100, "Daniel P. Berrange" 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