All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, dgilbert@redhat.com, lvivier@redhat.com,
	peterx@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/6] qio: Make port 0 work for qio
Date: Fri, 03 Nov 2017 10:23:35 +0100	[thread overview]
Message-ID: <877ev74sx4.fsf@secure.laptop> (raw)
In-Reply-To: <20171030204820.GA15154@redhat.com> (Daniel P. Berrange's message of "Mon, 30 Oct 2017 21:48:20 +0100")

"Daniel P. Berrange" <berrange@redhat.com> wrote:
> On Mon, Oct 30, 2017 at 12:21:07PM +0100, Juan Quintela wrote:
>> For tcp sockets we read back what is the socket/address.  So we know
>> what is the port that we are listening into.
>> 
>> Looked all callers of the function, and they just create the addr, use
>> it, and drop it, so no problem that we always update the port in the
>> address.
>
> Can you explain more why you need this ?

I need to get back somewhere the port that bind gave me.
I can do it later by hand.  But that function has one parameter that
says that it update the sockaddr that gets passed, and it don't do it.

Auditing all the users of it, they don't care (basically all of them
just free the addr after returning for this function).

But if you preffer that I do this directly on the migration code, I have
no problem with that.

> Nothing should be using the socket_listen() method directly any more IIRC,
> and for the QIOChannelSocket classes, you should not rely on the address that
> you pass in, being the same as the one that ultimately gets passed into the
> socket_listen() method.

Ok, I will change to do this directly on the migration code.

> Patches that I have pending change things so that listening happens in two
> phases. First we take the SocketAddress and do DNS resolution to create
> mutliple new SocketAddress structs. These are then passed into the lowlevel
> socket_listen() method. So with that happening, even if you update the address
> in socket_listen() that info won't get back upto the caller.
>
> If you have a QIOChannelSocket instance, and you want to know what port it
> ended up listening on, you should call qio_channel_socket_get_local_address()
> method instead, which returns a dynamically popualted SocketAddress struct.
> This should mean socket_listen() never needs to update the address that it
> binds on.

Ah, yet another function O:-)

Ok, I will use this one.  Sorry for the disturbance.

> IOW, I think this patch is redundant.

Later, Juan.

  reply	other threads:[~2017-11-03  9:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-30 11:21 [Qemu-devel] [PATCH 0/6] Improve info migrate output on destination Juan Quintela
2017-10-30 11:21 ` [Qemu-devel] [PATCH 1/6] qio: Make port 0 work for qio Juan Quintela
2017-10-30 20:48   ` Daniel P. Berrange
2017-11-03  9:23     ` Juan Quintela [this message]
2017-10-30 11:21 ` [Qemu-devel] [PATCH 2/6] migration: print features as on off Juan Quintela
2017-11-03 13:23   ` Dr. David Alan Gilbert
2017-11-08  8:13   ` Peter Xu
2017-10-30 11:21 ` [Qemu-devel] [PATCH 3/6] migration: free addr in the same function that we created it Juan Quintela
2017-11-08  8:15   ` Peter Xu
2017-10-30 11:21 ` [Qemu-devel] [PATCH 4/6] migration: Create uri parameter Juan Quintela
2017-10-30 11:21 ` [Qemu-devel] [PATCH 5/6] migration: Now set the migration uri Juan Quintela
2017-11-03 10:07   ` Daniel P. Berrange
2017-11-22 12:29     ` Juan Quintela
2017-11-22 12:54       ` Daniel P. Berrange
2017-11-22 12:58         ` Daniel P. Berrange
2017-11-29 16:43           ` Juan Quintela
2017-11-29 16:48             ` Daniel P. Berrange
2017-10-30 11:21 ` [Qemu-devel] [PATCH 6/6] migration: make migrate uri parameter optional Juan Quintela
2017-10-30 13:02 ` [Qemu-devel] [PATCH 0/6] Improve info migrate output on destination Fam Zheng

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=877ev74sx4.fsf@secure.laptop \
    --to=quintela@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.