[Libvir] [PATCH] docs spelling fixes
by Eduardo Habkost
Small spelling fixes on docs/format.html.
--- libvirt/docs/format.html 16 Jul 2007 21:30:30 -0000 1.25
+++ libvirt/docs/format.html 6 Sep 2007 17:29:51 -0000
@@ -59,7 +59,7 @@
</ul><p>The format of the devices and their type may grow over time, but the
following should be sufficient for basic use:</p><p>A <code>disk</code> device indicates a block device, it can have two
values for the type attribute either 'file' or 'block' corresponding to the 2
-options availble at the Xen layer. It has two mandatory children, and one
+options available at the Xen layer. It has two mandatory children, and one
optional one in no specific order:</p><ul><li>source with a file attribute containing the path in Domain 0 to the
file or a dev attribute if using a block device, containing the device
name ('hda5' or '/dev/hda5')</li>
@@ -72,7 +72,7 @@
number of children in no specific order:</p><ul><li>source: indicating the bridge name</li>
<li>mac: the optional mac address provided in the address attribute</li>
<li>ip: the optional IP address provided in the address attribute</li>
- <li>script: the script used to bridge the interfcae in the Domain 0</li>
+ <li>script: the script used to bridge the interface in the Domain 0</li>
<li>target: and optional target indicating the device name.</li>
</ul><p>A <code>console</code> element describes a serial console connection to
the guest. It has no children, and a single attribute <code>tty</code> which
@@ -237,11 +237,11 @@
<li>Virtual network
<p>Provides a virtual network using a bridge device in the host.
Depending on the virtual network configuration, the network may be
- totally isolated,NAT'ing to aan explicit network device, or NAT'ing to
+ totally isolated, NAT'ing to an explicit network device, or NAT'ing to
the default route. DHCP and DNS are provided on the virtual network in
all cases and the IP range can be determined by examining the virtual
network config with '<code>virsh net-dumpxml <network
- name></code>'. There is one virtual network called'default' setup out
+ name></code>'. There is one virtual network called 'default'' setup out
of the box which does NAT'ing to the default route and has an IP range of
<code>192.168.22.0/255.255.255.0</code>. Each guest will have an
associated tun device created with a name of vnetN, which can also be
@@ -311,7 +311,7 @@
</li>
<li>TCP tunnel
<p>A TCP client/server architecture provides a virtual network. One VM
- provides the server end of the netowrk, all other VMS are configured as
+ provides the server end of the network, all other VMS are configured as
clients. All network traffic is routed between the VMs via the server.
This mode is also available to unprivileged users. There is no default
DNS or DHCP support and no outgoing network access. To provide outgoing
@@ -411,7 +411,7 @@
</features>
</guest></span>
...
-</capabilities></pre><p>The fist block (in red) indicates the host hardware capbilities, currently
+</capabilities></pre><p>The fist block (in red) indicates the host hardware capabilities, currently
it is limited to the CPU properties but other information may be available,
it shows the CPU architecture, and the features of the chip (the feature
block is similar to what you will find in a Xen fully virtualized domain
--
Eduardo
16 years, 8 months
[Libvir] Documentation errors and shortcomings
by Tóth István
Hello!
I am currently working on java bindings for libvirt, and in the process
I have found a few bugs with the documentation, and also what I believe
to be a design problem in the API.
1. The parameterized C macros do not have their arguments listed either
on libvirt.org, or in the docs folder in the distribution list, even
though there is a a documentation block in the actual source file. I
guess it's some kind of problem with the tool used for generating the docs.
2. The virConnectGetCapabilities function docs says that it returns an
opaque pointer to a struct, when in fact it returns an XML string
describing the capabilities.
3. I have found no sanctioned way to actually get the data from
DomainBlockStats and DomainInterfaceStats.
The strucures are defined as _virDomainBlockStats and struct
_virDomainInterfaceStats, and there is only an *Ptr type typedef-ed on
them, as in the case of, say virConnectPtr, which IS really meant to be
opaque.
I believe that the fields of these structs ARE meant to be read by the
applications linking the library, and are not really meant to be
opaque. (or if they are, they should have some functions/macros that you
can access their contents with)
I think the right way to fix this would be simply to typedef them as
typedef struct _virDomainBlockStats virDomainBlockStats;
typedef struct _virDomainInterfaceStats DomainInterfaceStats;
expose their fields in the documentation, and not call them opaque (
i.e. treat them just like virSchedParameter)
best regards
István
16 years, 8 months
[Libvir] [PATCH] Support Sun's Compiler
by Mark Johnson
The following patch allows libvirt to be compiled
with Sun's CC compiler.
tested on today's CVS bits on a FC7 dom0
(LD_PRELOAD=src/.libs/libvirt.so src/.libs/virsh)
Thanks,
MRJ
16 years, 8 months
[Libvir] Documentation errors and shortcomings
by Toth Istvan
Hello!
I am currently working on java bindings for libvirt, and in the process
I have found a few bugs with the documentation, and also what I believe
to be a design problem in the API.
1. The parameterized C macros do not have their arguments listed either
on libvirt.org, or in the docs folder in the distribution list, even
though there is a a documentation block in the actual source file. I
guess it's some kind of problem with the tool used for generating the docs.
2. The virConnectGetCapabilities function docs says that it returns an
opaque pointer to a struct, when in fact it returns an XML string
describing the capabilities.
3. I have found no sanctioned way to actually get the data from
DomainBlockStats and DomainInterfaceStats.
The strucures are defined as _virDomainBlockStats and struct
_virDomainInterfaceStats, and there is only an *Ptr type typedef-ed on
them, as in the case of, say virConnectPtr, which IS really meant to be
opaque.
I believe that the fields of these structs ARE meant to be read by the
applications linking the library, and are not really meant to be
opaque. (or if they are, they should have some functions/macros that you
can access their contents with)
I think the right way to fix this would be simply to typedef them as
typedef struct _virDomainBlockStats virDomainBlockStats;
typedef struct _virDomainInterfaceStats DomainInterfaceStats;
expose their fields in the documentation, and not call them opaque (
i.e. treat them just like virSchedParameter)
best regards
István
16 years, 8 months
[Libvir] Documentation errors and shortcomings
by Toth Istvan
Hello!
I am currently working on java bindings for libvirt, and in the process
I have found a few bugs with the documentation, and also what I believe
to be a design problem in the API.
1. The parameterized C macros do not have their arguments listed either
on libvirt.org, or in the docs folder in the distribution list, even
though there is a a documentation block in the actual source file. I
guess it's some kind of problem with the tool used for generating the docs.
2. The virConnectGetCapabilities function docs says that it returns an
opaque pointer to a struct, when in fact it returns an XML string
describing the capabilities.
3. I have found no sanctioned way to actually get the data from
DomainBlockStats and DomainInterfaceStats.
The strucures are defined as _virDomainBlockStats and struct
_virDomainInterfaceStats, and there is only an *Ptr type typedef-ed on
them, as in the case of, say virConnectPtr, which IS really meant to be
opaque.
I believe that the fields of these structs ARE meant to be read by the
applications linking the library, and are not really meant to be
opaque. (or if they are, they should have some functions/macros that you
can access their contents with)
I think the right way to fix this would be simply to typedef them as
typedef struct _virDomainBlockStats virDomainBlockStats;
typedef struct _virDomainInterfaceStats DomainInterfaceStats;
expose their fields in the documentation, and not call them opaque (
i.e. treat them just like virSchedParameter)
best regards
István
16 years, 8 months
[Libvir] Memory leak in XenHypervisorMakeCapabilitiesXML?
by beth kon
Hi. Seems to me there is a memory leak with the strdup function in
xenHypervisorMakeCapabilitiesXML. Looking up the chain of calls leading
to xenHypervisorMakeCapabilitiesXML, I don't see the required free for
the hidden malloc in the strdup. The same problem may exist with other
strdups in the code.
--
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak(a)us.ibm.com
16 years, 8 months
[Libvir] build problem
by Mark Johnson
I'm having problems building the libvirt cvs bits (clean)
on FC 7. I'm sure I'm doing something stupid??
I don't see xdr_qemud_packet_client anywhere in the source?
Any ideas?
Thanks,
MRJ
../src/.libs/libvirt_la-qemu_internal.o: In function `qemuProcessRequest':
/home/mrj/libvirt/src/qemu_internal.c:312: undefined reference to
`xdr_qemud_packet_client'
/home/mrj/libvirt/src/qemu_internal.c:375: undefined reference to
`xdr_qemud_packet_server'
collect2: ld returned 1 exit status
make[3]: *** [xmlrpctest] Error 1
make[3]: Leaving directory `/home/mrj/libvirt.hg/tests'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mrj/libvirt.hg/tests'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/mrj/libvirt.hg'
make: *** [all] Error 2
16 years, 8 months
[Libvir] libvirt statistics
by Richard W.M. Jones
[Using `pahole' and friends - see
http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git;a=summary and
https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf ]
These are all on x86-64. You'll get slightly different results on a 32
bit arch.
Largest structures, by size:
qemud_vm_def: 16608 4
qemud_vm_os_def: 16436 1
_testConn: 14504 2
qemud_vm: 12368 2
qemud_network: 8240 0
qemud_vm_disk_def: 4376 2
qemud_driver: 4192 1
qemud_vm_net_def: 4136 2
xenXMConfCache: 4112 0
_virProxyFullPacket: 4096 0
_xmlParserCtxt: 696 5
_virDriver: 432 1
utsname: 390 0
_testDom: 360 0
_xmlXPathContext: 352 4
xenUnifiedDriver: 328 0
dirent: 280 0
_xmlSAXHandler: 256 1
_IO_FILE: 216 2
_xenUnifiedPrivate: 192 1
qemud_network_def: 192 2
_xmlDoc: 168 2
_virConnect: 168 0
_testNet: 156 0
Structures with holes which could be made smaller by packaging (third
number is how many bytes you'd save per allocation):
qemud_vm 12368 12360 8
qemud_vm_def 16608 16600 8
private_data 56 48 8
remote_domain_get_info_ret 40 32 8
XDR 48 40 8
xen_v0_vcpuinfo 40 32 8
_xmlValidCtxt 112 104 8
_xmlEntity 136 128 8
_xmlParserCtxt 696 672 24
_testConn 14504 14496 8
_xmlURI 80 72 8
_xmlXPathObject 72 56 16
_xmlXPathParserContext 80 72 8
_xmlXPathContext 352 336 16
_xmlError 88 80 8
_xmlAttr 96 88 8
_xmlDoc 168 160 8
_xmlNode 120 112 8
_IO_FILE 216 208 8
_virDomainInfo 40 32 8
Longest functions (NB: long functions are not a bad thing -- read Steve
McConnell).
qemudParseVMDef: 9680
doRemoteOpen: 6631
xenXMParseXMLToConfig: 5678
xenXMDomainFormatXML: 5678
xend_parse_sexp_desc: 5424
qemudBuildCommandLine: 5204
virDomainParseXMLDesc: 3503
qemudGenerateXML: 2556
__virErrorMsg: 2332
testOpenFromFile: 2210
call: 2206
qemudStartNetworkDaemon: 2105
virDomainParseXMLOSDescHVM: 2078
qemudParseNetworkDef: 2023
xenHypervisorMakeCapabilitiesXML: 1838
virDomainParseXMLDiskDesc: 1686
qemudStartVMDaemon: 1683
xenXMConfigCacheRefresh: 1547
xenXMParseXMLDisk: 1545
virConfParseValue: 1516
virConfParse: 1457
qemudScanConfigDir: 1396
testLoadNetwork: 1353
dhcpStartDhcpDaemon: 1259
virXen_getvcpusinfo: 1257
testLoadDomain: 1244
qemudDomainSave: 1194
virDomainParseXMLIfDesc: 1164
xenHypervisorInit: 1104
xenXMDomainDefineXML: 1083
iptablesAddRemoveRule: 1081
testOpen: 1075
Functions with the most variables (perhaps a better indicator of
"complexity", I know that doRemoteOpen is a bloody complicated function
for example):
xenXMDomainFormatXML: 18
virDomainParseXMLDesc: 18
doRemoteOpen: 18
testLoadDomain: 17
xenHypervisorMakeCapabilitiesXML: 16
testLoadNetwork: 15
xenXMParseXMLDisk: 14
xenStoreLookupByName: 13
xend_parse_sexp_desc: 13
virDomainParseXMLDiskDesc: 13
testOpenFromFile: 12
qemudBuildCommandLine: 12
xenStoreDomainGetNetworkID: 10
xenDaemonDomainGetVcpus: 10
virDomainParseXMLOSDescHVM: 10
qemudParseInterfaceXML: 10
xenXMParseXMLVif: 9
xenXMParseXMLToConfig: 9
xenXMDomainDefineXML: 9
query_parse: 9
iptablesAddRemoveRule: 9
xenStoreListDomains: 8
xenHypervisorLookupDomainByUUID: 8
xenHypervisorInit: 8
xenDaemonListDomainsOld: 8
virDomainParseXMLOSDescPV: 8
virDomainParseXMLIfDesc: 8
testNetworkDumpXML: 8
testDomainDumpXML: 8
qemudNetworkIfaceConnect: 8
qemudGenerateXML: 8
qemudDomainSave: 8
Functions with more than one "goto" label:
qemudAddIptablesRules: 10
doRemoteOpen: 4
xenDaemonOpen: 3
qemudStartNetworkDaemon: 3
qemudExtractVersionInfo: 3
xenXMDomainFormatXML: 2
xenHypervisorInit: 2
xend_parse_sexp_desc: 2
virParseXMLDevice: 2
__virGetNetwork: 2
__virGetDomain: 2
virDomainXMLDevID: 2
remoteForkDaemon: 2
query_parse: 2
qemudStartup: 2
qemudNetworkIfaceConnect: 2
qemudGenerateXML: 2
qemudBuildCommandLine: 2
negotiate_gnutls_on_connection: 2
Functions with the most parameters (in C these are dangerous because of
C's lousy typechecking):
__virRaiseError: 12
xenXMConfigSetIntFromXPath: 8
xenUnifiedDomainMigratePrepare: 8
xenDaemonDomainMigratePrepare: 8
__virDomainMigratePrepare: 8
remoteDomainMigratePrepare: 8
qemudReadMonitorOutput: 8
call: 8
xenXMConfigSetStringFromXPath: 7
xenUnifiedDomainMigratePerform: 7
xenDaemonDomainMigratePerform: 7
_virExec: 7
__virDomainMigratePerform: 7
remoteDomainMigratePerform: 7
xenUnifiedDomainMigrateFinish: 6
xend_op_ext2: 6
virXen_getvcpusinfo: 6
virExecNonBlock: 6
virExec: 6
virDomainParseXMLOSDescHVM: 6
__virDomainMigrateFinish: 6
virDomainMigrate: 6
remoteDomainMigrateFinish: 6
All global variables (nothing wrong with global variables, I say):
extern unsigned int __invalid_size_argument_for_IOC; /* 0 */
struct qemu_feature_flags arch_info_i686_flags[4]; /* 0 */
struct qemu_feature_flags arch_info_x86_64_flags[3]; /* 0 */
struct qemud_driver * qemu_driver; /* 0 */
struct qemu_arch_info qemudArchs[7]; /* 1 */
extern struct _IO_FILE * stderr; /* 9 */
extern struct _IO_FILE * stdin; /* 23 */
extern struct _IO_FILE * stdout; /* 23 */
enum /**/ virDrvOpenRemoteFlags; /* 0 */
struct xenUnifiedDriver xenDaemonDriver; /* 1 */
struct xenUnifiedDriver xenHypervisorDriver; /* 1 */
struct xenUnifiedDriver xenProxyDriver; /* 1 */
struct xenUnifiedDriver xenStoreDriver; /* 1 */
struct xenUnifiedDriver xenXMDriver; /* 1 */
extern xmlFreeFunc xmlFree; /* 3 */
extern xmlMallocFunc xmlMalloc; /* 0 */
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
16 years, 8 months
[Libvir] feature sujestions
by Márcio Parise Boufleur
Hello, I'm a grad student from Brazil. I was looking for some
interesting project to do as my final work and it I think that
contributing to your project would be a great achievement to me.
Do you have some kind list with feature suggestions? I am
particularly interested in remote administration. I helped a colleague
to write a graphical tool to administrate a remote Xen site last year.
Thank you.
MB
--
Computers are useless;
they can only give you answers!
-- Picasso
16 years, 8 months
