Re: [Qemu-devel] Unified Datagram Socket Transport

[Anton Ivanov]

Hi Jason, Hi Eric, hi list,

I have gone through all comments and addressed everything to which I did 
not reply separately with clarifications.

Before I resubmit I have a couple of architectural questions:

1. Is it OK in its current form: UDST client which cannot be 
instantiated and the others creating instances of it. I am aware that 
this does not quite match the current semantics, but this keeps the 
per-transport code to the minimum possible - init and (in the newest 
version) optional verify and form header functions. F.e. in the next 
submission raw will be init only and its data - nothing else.

2. I have updated the help, docs and the API.

3. I did not quite understand your comment on socket.c - what are you 
suggesting there - do you want to fold stream mode into a common 
backend? I do not think it is possible. I have tried to do surgery only 
on the datagram stuff. Also, socket.c is quite old and has a violations 
of current coding style and conventions. Should I fix those as a part of 
the submission or this can be a separate patch?

A.


On 21/07/17 04:55, Jason Wang wrote:
> On 2017年07月21日 03:12, address@hidden wrote:
> > Hi all,
> >
> > This addresses comments so far except Eric's suggestion to use
> > InetSocketAddressBase. If I understand correctly its intended use,
> > it will not be of help for protocols which have no port (raw
> > sockets - GRE, L2TPv3, etc).
> >
> > It also includes a port of the original socket.c transport to
> > the new UDST backend. The relevant code is ifdef-ed so there
> > should be no effect on other systems.
>
> This looks sub-optimal. If you want to do this, I would rather suggest 
> you just extend the socket dgram backend like what udst did now.
>
> > I think that this is would be the appropriate place to stop in this
> > iteration. I would prefer to have this polished, before I start
> > looking at sendmmsg and bulk send or some of the more unpleasant
> > encapsulations like geneve.
>
> Pay attention we're softfreeze now. So the feature is for 2.11, if it 
> looks good, I can only queue it for 2.11.
>
> Btw, looks like not all comments of v1 were addressed.
>
> Thanks
>
> > A.

--
Anton R. Ivanov

Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/