qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Yonit Halperin <yhalperi@redhat.com>
To: spice-devel@freedesktop.org, qemu-devel@nongnu.org, kraxel@redhat.com
Subject: Re: [Qemu-devel] [PATCH spice-server 08/13] server: move the linking of channels to a separate routine
Date: Sun, 25 Sep 2011 12:13:50 +0300	[thread overview]
Message-ID: <4E7EF0CE.1010400@redhat.com> (raw)
In-Reply-To: <20110922140100.GD2875@bow.tlv.redhat.com>

On 09/22/2011 05:01 PM, Alon Levy wrote:
> On Wed, Sep 21, 2011 at 06:51:18PM +0300, Yonit Halperin wrote:
>>
>> Signed-off-by: Yonit Halperin<yhalperi@redhat.com>
>> ---
>>   server/reds.c |   68 +++++++++++++++++++++++++++++++++++---------------------
>>   1 files changed, 42 insertions(+), 26 deletions(-)
>>
>> diff --git a/server/reds.c b/server/reds.c
>> index bea0eb0..e7388a0 100644
>> --- a/server/reds.c
>> +++ b/server/reds.c
>> @@ -2612,12 +2612,48 @@ static void inputs_init()
>>       reds_register_channel(channel);
>>   }
>>
>> +static void reds_send_input_channel_insecure_warn()
>> +{
>> +    RedsOutItem *item;
>> +    SpiceMsgNotify notify;
>> +    char *mess = "keyboard channel is insecure";
>> +    const int mess_len = strlen(mess);
>> +
>> +    item = new_out_item(SPICE_MSG_NOTIFY);
>> +
>> +    notify.time_stamp = get_time_stamp();
>> +    notify.severity = SPICE_NOTIFY_SEVERITY_WARN;
>> +    notify.visibilty = SPICE_NOTIFY_VISIBILITY_HIGH;
>> +    notify.what = SPICE_WARN_GENERAL;
>> +    notify.message_len = mess_len;
>> +
>> +    spice_marshall_msg_notify(item->m,&notify);
>> +    spice_marshaller_add(item->m, (uint8_t *)mess, mess_len + 1);
>> +
>> +    reds_push_pipe_item(item);
>> +}
>> +
>> +static void reds_channel_do_link(Channel *channel, SpiceLinkMess *link_msg, RedsStream *stream)
>> +{
>> +    uint32_t *caps;
>> +
>> +    ASSERT(channel);
>> +    ASSERT(link_msg);
>> +    ASSERT(stream);
>> +
>> +    if (link_msg->channel_type == SPICE_CHANNEL_INPUTS&&  !stream->ssl) {
>> +        reds_send_input_channel_insecure_warn();
>> +    }
>> +    caps = (uint32_t *)((uint8_t *)link_msg + link_msg->caps_offset);
>> +    channel->link(channel, stream, FALSE, link_msg->num_common_caps,
>> +                  link_msg->num_common_caps ? caps : NULL, link_msg->num_channel_caps,
>> +                  link_msg->num_channel_caps ? caps + link_msg->num_common_caps : NULL);
>> +}
>> +
>>   static void reds_handle_other_links(RedLinkInfo *link)
>>   {
>>       Channel *channel;
>> -    RedsStream *stream;
>>       SpiceLinkMess *link_mess;
>> -    uint32_t *caps;
>>
>>       link_mess = link->link_mess;
>>
>> @@ -2635,36 +2671,16 @@ static void reds_handle_other_links(RedLinkInfo *link)
>>       }
>>
>>       reds_send_link_result(link, SPICE_LINK_ERR_OK);
>> +    // TODO: if mig_target, where this call should be? here or only when the links are handled
> Both? add a prefix argument to reds_show_new_channel maybe.
>
Hi, my concern was more about the red_channel_event called from 
reds_show_new_channel. I think it should be called only once, and at the 
same place it is in these patches - when the client makes the initial 
connection to the target, i.e., before migration.
>>       reds_show_new_channel(link, reds->link_id);
>> -    if (link_mess->channel_type == SPICE_CHANNEL_INPUTS&&  !link->stream->ssl) {
>> -        RedsOutItem *item;
>> -        SpiceMsgNotify notify;
>> -        char *mess = "keyboard channel is insecure";
>> -        const int mess_len = strlen(mess);
>> -
>> -        item = new_out_item(SPICE_MSG_NOTIFY);
>> -
>> -        notify.time_stamp = get_time_stamp();
>> -        notify.severity = SPICE_NOTIFY_SEVERITY_WARN;
>> -        notify.visibilty = SPICE_NOTIFY_VISIBILITY_HIGH;
>> -        notify.what = SPICE_WARN_GENERAL;
>> -        notify.message_len = mess_len;
>> +    reds_stream_remove_watch(link->stream);
>>
>> -        spice_marshall_msg_notify(item->m,&notify);
>> -        spice_marshaller_add(item->m, (uint8_t *)mess, mess_len + 1);
>> +    reds_channel_do_link(channel, link->link_mess, link->stream);
>
> Would be nice to consistently use link_mess or link->link_mess, not both.
>
>> +    free(link_mess);
>>
>> -        reds_push_pipe_item(item);
>> -    }
>> -    stream = link->stream;
>> -    reds_stream_remove_watch(stream);
>>       link->stream = NULL;
>>       link->link_mess = NULL;
>>       reds_link_free(link);
>> -    caps = (uint32_t *)((uint8_t *)link_mess + link_mess->caps_offset);
>> -    channel->link(channel, stream, reds->mig_target, link_mess->num_common_caps,
>> -                  link_mess->num_common_caps ? caps : NULL, link_mess->num_channel_caps,
>> -                  link_mess->num_channel_caps ? caps + link_mess->num_common_caps : NULL);
>> -    free(link_mess);
>>   }
>>
>>   static void reds_handle_link(RedLinkInfo *link)
>> --
>> 1.7.4.4
>>

  reply	other threads:[~2011-09-25  9:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-21 15:51 [Qemu-devel] [PATCH spice-server 00/13] semi-seamless migration v2 (RHBZ #738266, 725009) Yonit Halperin
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 01/13] server/spice.h: semi-seamless migration interface, RHBZ #738266 Yonit Halperin
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 02/13] server: handle migration interface addition Yonit Halperin
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 03/13] configure: spice-protocol >= 0.8.2 (semi-seamless migration protocol) Yonit Halperin
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 04/13] server, proto: tell the client to connect to the migration target before migraton starts Yonit Halperin
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 05/13] spice.proto: add SPICE_MSG_MAIN_MIGRATE_END & SPICE_MSGC_MAIN_MIGRATE_END Yonit Halperin
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 06/13] server: send SPICE_MSG_MAIN_MIGRATE_END on spice_server_migrate_end Yonit Halperin
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 07/13] server: move SPICE_MSG_MAIN_INIT sending code to a separate routine Yonit Halperin
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 08/13] server: move the linking of channels " Yonit Halperin
2011-09-22 14:01   ` Alon Levy
2011-09-25  9:13     ` Yonit Halperin [this message]
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 09/13] server: handling semi-seamless migration in the target side Yonit Halperin
2011-09-22 14:28   ` Alon Levy
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 10/13] server: call migrate_connect_complete callback when no client is connected Yonit Halperin
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 11/13] server: turn spice_server_migrate_start into a valid call Yonit Halperin
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 12/13] server: fall back to switch host scheme in case semi-seamless connection to target fails Yonit Halperin
2011-09-22 14:38   ` Alon Levy
2011-09-21 15:51 ` [Qemu-devel] [PATCH spice-server 13/13] Release 0.8.3 Yonit Halperin
2011-09-22 14:50 ` [Qemu-devel] [PATCH spice-server 00/13] semi-seamless migration v2 (RHBZ #738266, 725009) Alon Levy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E7EF0CE.1010400@redhat.com \
    --to=yhalperi@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=spice-devel@freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).