Re: [PATCH 02/15] Change vdi_port_read_buf_process() to take RedsState arg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2016-01-19 at 05:12 -0500, Frediano Ziglio wrote:
> > 
> > Hi,
> > 
> > On Mon, 2016-01-18 at 16:37 +0000, Frediano Ziglio wrote:
> > > From: Jonathon Jongsma <jjongsma@xxxxxxxxxx>
> > > 
> > > ---
> > >  server/reds.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/server/reds.c b/server/reds.c
> > > index 25e9f90..b347d1d 100644
> > > --- a/server/reds.c
> > > +++ b/server/reds.c
> > > @@ -662,7 +662,7 @@ static void vdi_port_read_buf_release(uint8_t
> > > *data, void *opaque)
> > >  }
> > >  
> > >  /* returns TRUE if the buffer can be forwarded */
> > > -static int vdi_port_read_buf_process(int port, VDIReadBuf *buf)
> > > +static int vdi_port_read_buf_process(RedsState *reds, int port,
> > > VDIReadBuf *buf)
> > 
> > I like when the first parameter corresponds with the function name.
> > Moving reds to the last position?
> > 
> > Reviewed-by: Pavel Grunt <pgrunt@xxxxxxxxxx>
> > 
> 
> Usually I agree with you but usually these class of functions have
> the same
> first parameters. It's kind of this in C++ or self in python. They
> specify
and some comments say "More consistent with glib naming conventions"
> the object they are working on. But in this case many vdi_port
> functions don't
> have a port parameter (actually only one) so
Yeah, I noticed that in the following patches. I would prefer if we
could follow some (naming) style.

> Acked-by: Frediano Ziglio <fziglio@xxxxxxxxxx>
> 
> However as Fabiano say (and I agree) a Nack is stronger than an Ack.
> 
> Frediano

I didn't say nack, just asked for an opinion.

Pavel


> 
> 
> > >  {
> > >      VDIPortState *state = &reds->agent_state;
> > >      int res;
> > > @@ -787,7 +787,7 @@ static SpiceCharDeviceMsgToClient
> > > *vdi_port_read_one_msg_from_device(SpiceCharDe
> > >              } else {
> > >                  state->read_state =
> > > VDI_PORT_READ_STATE_GET_BUFF;
> > >              }
> > > -            if (vdi_port_read_buf_process(state-
> > > > vdi_chunk_header.port, dispatch_buf)) {
> > > +            if (vdi_port_read_buf_process(reds, state-
> > > > vdi_chunk_header.port, dispatch_buf)) {
> > >                  return dispatch_buf;
> > >              } else {
> > >                  vdi_port_read_buf_unref(dispatch_buf);
> > > @@ -1156,7 +1156,7 @@ void
> > > reds_on_main_channel_migrate(MainChannelClient *mcc)
> > >                      !agent_state->read_filter.msg_data_to_read);
> > >  
> > >          read_buf->len = read_data_len;
> > > -        if (vdi_port_read_buf_process(agent_state-
> > > > vdi_chunk_header.port, read_buf)) {
> > > +        if (vdi_port_read_buf_process(reds, agent_state-
> > > > vdi_chunk_header.port, read_buf)) {
> > >              main_channel_client_push_agent_data(mcc,
> > >                                                  read_buf->data,
> > >                                                  read_buf->len,
> > 
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]