qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Harsh Bora <harsh@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org,
	"Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] VirtIO 9p mount_tag (bogus?) limit of 32 bytes
Date: Wed, 28 Sep 2011 16:18:07 +0100	[thread overview]
Message-ID: <20110928151807.GU21102@redhat.com> (raw)
In-Reply-To: <4E830A66.50605@linux.vnet.ibm.com>

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.

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

  reply	other threads:[~2011-09-28 15:18 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 [this message]
2011-09-29 15:22     ` Aneesh Kumar K.V
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=20110928151807.GU21102@redhat.com \
    --to=berrange@redhat.com \
    --cc=aneesh.kumar@linux.vnet.ibm.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).