From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54273) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3aSn-0003sC-N1 for qemu-devel@nongnu.org; Thu, 19 May 2016 22:46:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b3aSk-0004b0-GM for qemu-devel@nongnu.org; Thu, 19 May 2016 22:46:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3aSk-0004au-7c for qemu-devel@nongnu.org; Thu, 19 May 2016 22:46:54 -0400 References: <1460977906-25218-1-git-send-email-zhangchen.fnst@cn.fujitsu.com> <1460977906-25218-2-git-send-email-zhangchen.fnst@cn.fujitsu.com> <5721B379.5080809@redhat.com> <5721B8D0.3030700@redhat.com> <5721C1E8.4040409@cn.fujitsu.com> <5721C6FE.6050301@redhat.com> <5721D21C.6070202@cn.fujitsu.com> <5722C0D6.8080805@redhat.com> <572C2EB4.1090005@cn.fujitsu.com> <572C3BAF.5080106@redhat.com> <57306B3C.5090000@cn.fujitsu.com> <5734275C.8070406@cn.fujitsu.com> <5734385B.6040004@redhat.com> <57343BD0.5060206@cn.fujitsu.com> <57354E7C.6040408@redhat.com> From: Jason Wang Message-ID: <573E7A94.8090306@redhat.com> Date: Fri, 20 May 2016 10:46:44 +0800 MIME-Version: 1.0 In-Reply-To: <57354E7C.6040408@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH V3 1/4] colo-compare: introduce colo compare initlization List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhang Chen , qemu devel Cc: zhanghailiang , Li Zhijian , Gui jianfeng , "eddie.dong" , "Dr. David Alan Gilbert" , Amit Shah , Yang Hongyang , famz@redhat.com On 2016=E5=B9=B405=E6=9C=8813=E6=97=A5 11:48, Jason Wang wrote: > > > On 2016=E5=B9=B405=E6=9C=8812=E6=97=A5 16:16, Zhang Chen wrote: >> >> >> On 05/12/2016 04:01 PM, Jason Wang wrote: >>> >>> >>> On 2016=E5=B9=B405=E6=9C=8812=E6=97=A5 14:49, Zhang Chen wrote: >>>> >>>> >>>> On 05/09/2016 06:49 PM, Zhang Chen wrote: >>>>> >>>>>> + >>>>>> + s->chr_sec_in =3D qemu_chr_find(s->sec_indev); >>>>>> + if (s->chr_sec_in =3D=3D NULL) { >>>>>> + error_setg(errp, "Secondary IN Device '%s' not found", >>>>>> + s->sec_indev); >>>>>> + return; >>>>>> + } >>>>>> + >>>>>> + s->chr_out =3D qemu_chr_find(s->outdev); >>>>>> + if (s->chr_out =3D=3D NULL) { >>>>>> + error_setg(errp, "OUT Device '%s' not found", s->outdev); >>>>>> + return; >>>>>> + } >>>>>> + >>>>>> + qemu_chr_fe_claim_no_fail(s->chr_pri_in); >>>>>> + qemu_chr_add_handlers(s->chr_pri_in, compare_chr_can_read, >>>>>> + compare_pri_chr_in, NULL, s); >>>>>> + >>>>>> + qemu_chr_fe_claim_no_fail(s->chr_sec_in); >>>>>> + qemu_chr_add_handlers(s->chr_sec_in, compare_chr_can_read, >>>>>> + compare_sec_chr_in, NULL, s); >>>>>> + >>>>>>>>>>>> Btw, what's the reason of handling this in main loop? I=20 >>>>>>>>>>>> thought it >>>>>>>>>>>> would >>>>>>>>>>>> be better to do this in colo thread? Otherwise, you need=20 >>>>>>>>>>>> lots of >>>>>>>>>>>> extra >>>>>>>>>>>> synchronizations? >>>>>>>>>>> Do you mean we should start/stop/do checkpoint it by=20 >>>>>>>>>>> colo-frame? >>>>>>>>>> I mean we probably want to handle pri_in and sec_in in colo=20 >>>>>>>>>> compare >>>>>>>>>> thread. Through this way, there's no need for extra=20 >>>>>>>>>> synchronization >>>>>>>>>> with >>>>>>>>>> main loop. >>>>>>>>> I get your point, but how to do this. >>>>>>>>> Now, we use qemu_chr_add_handlers to do this job. >>>>>>>> You probably want to start a new main loop in colo comparing=20 >>>>>>>> thread. >>>>>>> >>>>>>> IIUC, do you mean >>>>>>> - remove char device read_handler >>>>>>> >>>>>>> =E2=86=93at colo comparing thread=E2=86=93 >>>>>>> while (true) { >>>>>>> - blocking read packet from char device with select(2)/poll(2)... >>>>>>> - compare packet >>>>>>> } >>>>>> Yes, something like this. >>>>>> >>>>> >>>>> But remove qemu_chr_add_handlers I can't get fd to select/poll. >>>>> >>>>> How to get fd from all kinds of chardev? >>>>> >>>> >>>> Hi~ jason. >>>> >>>> If we use chardev socket the fd save in QIOChannelSocket. >>>> >>>> and if we use chardev file the fd save in QIOChannelFile. >>>> >>>> Have any common method to get fd? >>> >>> I'm not sure I get the question. But you probably can call=20 >>> qemu_chr_add_handlers() in colo comparing thread to solve this I thin= k? >>> >> >> I have tested call qemu_chr_add_handlers() in colo comparing thread,=20 >> but when data come, >> the handler always running in main loop. >> >> Thanks >> Zhang Chen=20 > > Cc Amit for the help. > > Amit, we want to poll and handle chardev in another thread other than=20 > main loop. But looks like qemu_chr_add_handlers() can only work for=20 > default context other than thread default context. Any other solution=20 > for this? > > Thanks > Cc Fam for more thought.