From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: aliguori@us.ibm.com,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: [Qemu-devel] [PATCH 2/2] qemu-options.hx: Update virtfs command documentation
Date: Mon, 6 Jun 2011 22:47:54 +0530 [thread overview]
Message-ID: <1307380674-2166-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com> (raw)
In-Reply-To: <1307380674-2166-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
Clarify the virtfs option better
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
qemu-options.hx | 116 ++++++++++++++++++++++++++++++++++---------------------
1 files changed, 72 insertions(+), 44 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 4789fe4..c6fb12c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -483,6 +483,8 @@ possible drivers and properties, use @code{-device ?} and
@code{-device @var{driver},?}.
ETEXI
+DEFHEADING()
+
DEFHEADING(File system options:)
DEF("fsdev", HAS_ARG, QEMU_OPTION_fsdev,
@@ -492,34 +494,54 @@ DEF("fsdev", HAS_ARG, QEMU_OPTION_fsdev,
STEXI
-The general form of a File system device option is:
-@table @option
-
@item -fsdev @var{fstype} ,id=@var{id} [,@var{options}]
@findex -fsdev
-Fstype is one of:
-@option{local},
-The specific Fstype will determine the applicable options.
-
-Options to each backend are described below.
-
-@item -fsdev local ,id=@var{id} ,path=@var{path} ,security_model=@var{security_model}[,cache=@var{cache}]
-
-Create a file-system-"device" for local-filesystem.
-@option{local} is only available on Linux.
-
-@option{path} specifies the path to be exported. @option{path} is required.
+Define a new file system device. Valid options are
+@table @option
+@item local
+This option create a file-system-"device" for local-filesystem.
+Currently only local file system device is supported.
+@item id=@var{id}
+Identifier for this device
+@item path=@var{path}
+This option define the export path for the file system device.
+Files below this path will be available for 9p client on the
+guest.
+@item security_model=@var{security_model}
+This option define the security model to be used when exporting
+the files. The supported security models are passthrough, mapped
+and none. In passthrough security model, file are stored using
+the same credentials as they are created on the guest. This require
+qemu to run as root. In the mapped security model, some of the
+file attributes like uid, gid, mode bits and link target are
+stored as file attributes. Directories exported by this security
+model cannot interact with other unix tools. "none" security model
+is same as passthrough expect they won't report failures if
+the sever fails to set file attributes like ownership.
+@item cache=@var{cache}
+This is an optional argument. The support value is writethrough
+This means thatthe host page cache will be used to read and write
+data but write notification will be sent to the guest only when
+the data has been reported as written by the storage subsystem.
-@option{security_model} specifies the security model to be followed.
-@option{security_model} is required.
+@end table
-@option{cache} specifies whether to skip the host page cache.
-@option{cache} is an optional argument.
+-fsdev option is used along with -device driver "virtio-9p-pci"
+Option for virtio-9p-pci driver are
+@table @option
+@item fsdev=@var{id}
+This option specify the @var{id} value specified along with -fsdev option
+@item mount_tag=@var{mount_tag}
+This option specifies the tag name to be used by the guest
+to mount this export point
@end table
+
ETEXI
+DEFHEADING()
+
DEFHEADING(Virtual File system pass-through options:)
DEF("virtfs", HAS_ARG, QEMU_OPTION_virtfs,
@@ -529,33 +551,39 @@ DEF("virtfs", HAS_ARG, QEMU_OPTION_virtfs,
STEXI
-The general form of a Virtual File system pass-through option is:
-@table @option
-
-@item -virtfs @var{fstype} [,@var{options}]
-@findex -virtfs
-Fstype is one of:
-@option{local},
-The specific Fstype will determine the applicable options.
-
-Options to each backend are described below.
-
@item -virtfs local ,path=@var{path} ,mount_tag=@var{mount_tag} ,security_model=@var{security_model}[,cache=@var{cache}]
+@findex -virtfs
-Create a Virtual file-system-pass through for local-filesystem.
-
-@option{local} is only available on Linux.
-
-@option{path} specifies the path to be exported. @option{path} is required.
-
-@option{security_model} specifies the security model to be followed.
-@option{security_model} is required.
-
-@option{mount_tag} specifies the tag with which the exported file is mounted.
-@option{mount_tag} is required.
-
-@option{cache} specifies whether to skip the host page cache.
-@option{cache} is an optional argument.
+The general form of a Virtual File system pass-through option is:
+@table @option
+@item local
+This option create a file-system-"device" for local-filesystem.
+Currently only local file system device is supported.
+@item id=@var{id}
+Identifier for this device
+@item path=@var{path}
+This option define the export path for the file system device.
+Files below this path will be available for 9p client on the
+guest.
+@item mount_tag=@var{mount_tag}
+This option specifies the tag name to be used by the guest
+to mount this export point
+@item security_model=@var{security_model}
+This option define the security model to be used when exporting
+the files. The supported security models are passthrough, mapped
+and none. In passthrough security model, file are stored using
+the same credentials as they are created on the guest. This require
+qemu to run as root. In the mapped security model, some of the
+file attributes like uid, gid, mode bits and link target are
+stored as file attributes. Directories exported by this security
+model cannot interact with other unix tools. "none" security model
+is same as passthrough expect they won't report failures if
+the sever fails to set file attributes like ownership.
+@item cache=@var{cache}
+This is an optional argument. The support value is writethrough
+This means thatthe host page cache will be used to read and write
+data but write notification will be sent to the guest only when
+the data has been reported as written by the storage subsystem.
@end table
ETEXI
--
1.7.4.1
next prev parent reply other threads:[~2011-06-06 17:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-06 17:17 [Qemu-devel] [PATCH 1/2] hw/9pfs: Add new virtfs option cache=writethrough to skip host page cache Aneesh Kumar K.V
2011-06-06 17:17 ` Aneesh Kumar K.V [this message]
2011-06-09 7:50 ` [Qemu-devel] [PATCH 2/2] qemu-options.hx: Update virtfs command documentation Markus Armbruster
-- strict thread matches above, loose matches on Subject: below --
2011-10-07 6:46 [Qemu-devel] [PATCH 1/2] hw/9pfs: Add new virtfs option cache=writethrough to skip host page cache Aneesh Kumar K.V
2011-10-07 6:46 ` [Qemu-devel] [PATCH 2/2] qemu-options.hx: Update virtfs command documentation Aneesh Kumar K.V
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=1307380674-2166-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=aliguori@us.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).