"Daniel P. Berrange" <berra...@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.
