The suggested XML description follows the logical structure of the
data, one top smbios description, with one or more blocks, each
containing the entries, the example below gives an idea:
<smbios>
<table type="0">
<entry name="Vendor">QEmu/KVM</entry>
<entry name="Version">0.13</entry>
</table>
<table type="1">
<entry name="Manufacturer">Fedora</entry>
<entry name="Product">Virt-Manager</entry>
<entry name="Version">0.8.2-3.fc14</entry>
<entry name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
</table>
</smbios>
I didn't tried in the RNG and in the conf parser in general to wire
down the description to the very limited set actually allowed by QEmu,
but tried to stay generic. However a lot of the smbios data has
'no serviceable parts' inside, and is mostly a binary blob with various
data encoded in binary, but I think the above model is sufficiently
flexible and common to allow setting other various types of data.
To avoid problems with space normalization in attribute values, I
preferred to encode the entry content as text node chidren of entries
rather than use an attribute. The name descriptions used by the
standard are simple enough that they should not be a problem in
attributes.
In the schemas I currently limit to only type 0 and 1, I could remove
that and limit to 0..32 since that's the set allowed by the spec, but
other blocks are a priori harder to use in virtualization at least when
and user describes a domain.
Daniel
diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
index a934a77..a42961c 100644
--- a/docs/schemas/domain.rng
+++ b/docs/schemas/domain.rng
@@ -30,6 +30,9 @@
<optional>
<ref name="cpu"/>
</optional>
+ <optional>
+ <ref name="smbios"/>
+ </optional>
<ref name="os"/>
<ref name="clock"/>
<ref name="resources"/>
@@ -1746,6 +1749,51 @@
</element>
</define>
+ <!--
+ SMBIOS specification
+ The DMTF spec doesn't specify any string subset, just 0 terminated
+ byte strings, but better be safe and restrict at least the names
+ to avoid problems with space normalization in attribute values,
+ the value is kept as the element body for maximum flexibility.
+ A priori we allow only type 0 and type 1 string updates
+ -->
+ <define name="smbios">
+ <element name="smbios">
+ <zeroOrMore>
+ <element name="table">
+ <attribute name="type">
+ <ref name="smbios-type"/>
+ </attribute>
+ <oneOrMore>
+ <element name="entry">
+ <attribute name="name">
+ <ref name="smbios-name"/>
+ </attribute>
+ <ref name="smbios-value"/>
+ </element>
+ </oneOrMore>
+ </element>
+ </zeroOrMore>
+ </element>
+ </define>
+
+ <define name="smbios-type">
+ <data type="int">
+ <param name="minInclusive">0</param>
+ <param name="maxInclusive">1</param>
+ </data>
+ </define>
+
+ <define name="smbios-name">
+ <data type="string">
+ <param name='pattern'>[a-zA-Z0-9\-_\. ]+</param>
+ </data>
+ </define>
+
+ <define name="smbios-value">
+ <data type="string"/>
+ </define>
+
<define name="address">
<element name="address">
<choice>
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list