On 7/8/13 9:58 , "Laszlo Ersek" <ler...@redhat.com> wrote:
>On 07/05/13 19:06, Tomoki Sekiyama wrote:
>> On 7/4/13 8:54 , "Paolo Bonzini" <pbonz...@redhat.com> wrote:
>>
>>> Il 03/07/2013 18:19, Tomoki Sekiyama ha scritto:
>>>> On 7/3/13 11:58 , "Paolo Bonzini" <pbonz...@redhat.com> wrote:
>>>>
>>>>> Il 03/07/2013 17:49, Tomoki Sekiyama ha scritto:
>>>>>> - return ga_install_service(path, log_filepath,
>>>>>> fixed_state_dir);
>>>>>> + if (ga_install_vss_provider()) {
>>>>>> + return EXIT_FAILURE;
>>>>>> + }
>>>>>> + if (ga_install_service(path, log_filepath,
>>>>>> fixed_state_dir)) {
>>>>>> + ga_uninstall_vss_provider();
>>>>>> + return EXIT_FAILURE;
>>>>>> + }
>>>>>> + return 0;
>>>>>> } else if (strcmp(service, "uninstall") == 0) {
>>>>>> + ga_uninstall_vss_provider();
>>>>>> return ga_uninstall_service();
>>>>>
>>>>> I think this shouldn't be a hard failure. Only the freeze/thaw
>>>>> commands
>>>>> should fail.
>>>>>
>>>>> Paolo
>>>>
>>>> Do you mean that qemu-ga should work without qga-provider.dll etc.
>>>> even if it is configured --with-vss-sdk ?
>>>
>>> Yes, and I'm even wondering if we should move all VSS code to a DLL
>>> (provider and requestor---they are very tied to each other anyway
>>> because of hEventFrozen/hEventThaw), and have qemu-ga simply look for
>>> qga-provider.dll dropped into the executable directory.
>>>
>>> Then qemu-ga can look for it even if it is not configured
>>>--with-vss-sdk.
>>
>> Hm, that sounds reasonable.
>>
>> I will try on moving the requestor into qga-provider.dll at next
>> iteration.
>
>Is it OK with you if I skip reviewing v5 then? If the v5->v6
>reorganization is going to be intrusive (ie. I won't be able to do a
>patch-by-patch interdiff), then I'd prefer skipping v5.
Yes. I appreciate your review for the next version.
It actually requires some rework especially in "Error" handling in
the requester, because I'd not like to link glib and some other dlls
to VSS system service.... May be need to give function pointer of
error_set_win32() to the dll, or something like that.
Thanks,
Tomoki Sekiyama
