On 02/25/13 22:01, Eric Blake wrote:
On 02/25/2013 02:08 AM, Peter Krempa wrote:
> On 02/22/13 19:20, Eric Blake wrote:
>> On 02/21/2013 07:47 AM, Peter Krempa wrote:
>>> This patch documents XML elements used for (basic) support of virtual
>>> RNG devices.
>>>
>>>
>>> For the slightly more advanced EGD backend:
>>> <devices>
>>> <rng model='virtio'>
>>> <backend model='egd' type='udp'>
>>> <!-- this is a definition of a character device -->
>>> <source mode='bind' service='1234'/>
>>> <source mode='connect' host='1.2.3.4'
service='1234'/>
>>> <!-- or other valid character device configuration -->
>>
>> Do we really want two <source> in a single <backend> in the example,
or
>> would it be easier to show multiple <rng> devices, one for each type of
>> backend?
>
> That actually is valid for the character device backends. The UDP
> backend has to use two separate sources for bi-directional
> communication. The definition of that source type is declared as a type
> in our RNG schema an I merely reused that.
Oh, I didn't realize that. Do we want to ENFORCE that there are two
<source> elements present then? Or can we always provide a sane default
when the user provides only 0 or 1 source? Depending on that answer, it
might be worth additional documentation on why two <source> elements are
present, as well as mentioning that order is significant in how they are
listed.
I reused the code to facilitate the operations done with character
devices. There's present infrastructure [1] that allows to parse, format
and create commandlines for qemu. The defaults for the syntax of the XML
and the expected values should be documented in the section describing
character devices. (But I did not really check if the description is
exhaustive)
In hindsight I should have linked that section in the description of the
egd backend model explicitly rather than by just mentioning it.
Peter
[1]: virDomainChrSourceDefParseXML, virDomainChrSourceDefFormat,
qemuBuildChrChardevStr