qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: "Daniel P. Berrange" <berrange@redhat.com>,
	Harsh Bora <harsh@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] VirtIO 9p mount_tag (bogus?) limit of 32 bytes
Date: Thu, 29 Sep 2011 20:52:14 +0530	[thread overview]
Message-ID: <87fwjfqspl.fsf@skywalker.in.ibm.com> (raw)
In-Reply-To: <20110928151807.GU21102@redhat.com>

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

  reply	other threads:[~2011-09-29 15:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-22 17:42 [Qemu-devel] VirtIO 9p mount_tag (bogus?) limit of 32 bytes Daniel P. Berrange
2011-09-28 11:52 ` Harsh Bora
2011-09-28 15:18   ` Daniel P. Berrange
2011-09-29 15:22     ` Aneesh Kumar K.V [this message]
2011-09-29 15:45       ` Daniel P. Berrange
  -- strict thread matches above, loose matches on Subject: below --
2012-02-16 12:20 C Anthony Risinger
2012-02-16 20:54 ` Paul Brook
2012-02-18 17:38 ` Aneesh Kumar K.V
2012-02-22  3:58   ` C Anthony Risinger
2012-02-23 18:08     ` Aneesh Kumar K.V
2012-03-07 16:29     ` M. Mohan Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fwjfqspl.fsf@skywalker.in.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=berrange@redhat.com \
    --cc=harsh@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).