[libvirt] [PATCH 1/3] qemu: Allow to specify the sysfs root for qemuBuildCommandLine

Osier Yang jyang at redhat.com
Wed May 15 11:23:04 UTC 2013


On 15/05/13 19:09, Daniel P. Berrange wrote:
> On Wed, May 15, 2013 at 12:07:42PM +0100, Daniel P. Berrange wrote:
>> On Wed, May 15, 2013 at 06:52:44PM +0800, Osier Yang wrote:
>>> Since 0d70656afded, it starts to access the sysfs files to build
>>> the qemu command line (by virSCSIDeviceGetSgName, which is find
>>> out the scsi generic device name by adpater:bus:target:unit), there
>>> is no way to work around, qemu wants to see the scsi generic device
>>> like "/dev/sg6" anyway.
>>>
>>> And I think it's not only the place which needs to access sysfs
>>> files when building qemu command line in future.
>>>
>>> As a solution, this introduces a new argument "sysfs_root" for
>>> qemuBuildCommandLine, and thus the tests can feed the fake sysfs
>>> root to it.
>> IMHO it would be nicer to detach the command line generator
>> code from any use of sysfs in this case.
>>
>> Instead of having QEMU call virSCSIDeviceGetSgName() directly,
>> pass in a callback for it to use to resolve the device path.
>>
>> eg
>>
>>    typedef char *(*qemuGetSCSIDevice)(const char *adapter,
>>                                       unsigned int bus,
>>                                       unsigned int target,
>>                                       unsigned int unit);

Nice idea.

>>
>> the qemuProcessStart code can pass in an impl of that callback

I guess you meant qemuBuildCommandLine or so, tests won't
call  qemuProcessStart. to start the guest.

>> which calls  virSCSIDeviceGetSgName(), while the test suite
>> can pass in an impl which returns a hard-coded device string.
> In fact there are probably other cases where we should pass in
> callbacks like this to the QEMU command line builder. Instead of
> adding many parameters to the API, we could provide a struct

Agreed, many params is always not good. .

> containing all the various callbacks needed in one go.
>
> Daniel

Osier




More information about the libvir-list mailing list