[PATCH 2/4] qmi-codegen: add support for gdouble

[Dan Williams]

On Fri, 2018-02-09 at 19:23 +0100, Thomas Weißschuh wrote:
> Hi,
> 
> On Fri, 2018-02-09T09:48-0600, Dan Williams wrote:
> > On Sun, 2018-01-28 at 16:50 +0100, Thomas Weißschuh wrote:
> > > ---
> > >  build-aux/qmi-codegen/VariableInteger.py           |  4 +++-
> > >  build-aux/qmi-codegen/utils.py                     |  5 +---
> > >  .../libqmi-glib/libqmi-glib-common.sections        |  1 +
> > >  src/libqmi-glib/qmi-message.c                      | 27
> > > ++++++++++++++++++++++
> > >  src/libqmi-glib/qmi-message.h                      | 26
> > > +++++++++++++++++++++
> > >  5 files changed, 58 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/build-aux/qmi-codegen/VariableInteger.py b/build-
> > > aux/qmi-codegen/VariableInteger.py
> > > index 12d2a77..1a3001e 100644
> > > --- a/build-aux/qmi-codegen/VariableInteger.py
> > > +++ b/build-aux/qmi-codegen/VariableInteger.py
> > > @@ -30,7 +30,7 @@ Variable type for signed/unsigned Integers and
> > > floating point numbers:
> > >   'guint32', 'gint32'
> > >   'guint64', 'gint64'
> > >   'guint-sized'
> > > - 'gfloat'
> > > + 'gfloat', 'gdouble'
> > >  """
> > >  class VariableInteger(Variable):
> > >  
> > > @@ -185,6 +185,8 @@ class VariableInteger(Variable):
> > >              common_format = '%" G_GINT64_FORMAT "'
> > >          elif self.private_format == 'gfloat':
> > >              common_format = '%f'
> > > +        elif self.private_format == 'gdouble':
> > > +            common_format = '%f'
> > >  
> > >          translations = { 'lp'             : line_prefix,
> > >                           'private_format' : self.private_format,
> > > 
> > 
> > In the patches I did, there were two more spots that I changed:
> > 
> > emit_buffer_read() and emit_buffer_write()
> > 
> > not sure if those are needed but since they handled gfloat
> > specifically, I figured they needed changing for gdouble
> > too.  Here's
> > the patch I used for that:
> 
> I am currently unsure about the endianess for gdoubles.
> For gfloat no endianess conversion is performed although they are 4
> bytes long.
> So either
> * gfloat are broken currently.
> * gfloat are transmitted without endianess issues. This would
> probably also
>   apply to gdouble and we could remove the endianess logic.
> 
> Do you have insights into this?
> (Probably in some documentation of the QMI protocol).

I certainly don't have access to that since you have to have an NDA to
get it.  But I believe all the QMI messages are little-endian, so it
may well be the case that gfloat is busted on BE arches since it's not
swapped.

What we should really do is create some unit tests that construct the
LE and BE final host values from byte arrays (so that we guarantee
LE/BE byte order) and then test the swapped values against that.  But
if gfloat is already broken, we don't need to block these patches on
making that testcase.

Dan