On Tue, 2014-03-04 at 09:42 +0100, Daniel Wagner wrote:
> > The attached patch changes it to use 64 bit data. Currently it makes
> > no attempt to maintain compatibility as both the format of the data
> > file and the DBus API changes. I see little advantage in maintaining
> > compatibility with the data file.
>
> I agree. Maybe one option would to have a small migration tool. E.g.
> there is under tools a program called stats-tool.c which could be
> doing this. If you are it, I would not mind having it updated to u64
> too :)
It's trivial and less error prone to be able to read the old format for
some amount of versions but write only the new one.
The only interesting question is how much of the data has been lost to
wraparounds already and whether everybody can live with the limitation
that starting with some version of ConnMan, the stats go back to zero.
I'd quickly guess everybody, but one never knows.
> > The data type of the counter fields are not documented in the
> > counter-api.txt file.
That's a really bad omission on our part. That means everybody has
fished out the data type from the D-Bus messages, i.e. it's been given
an undocumented de-facto type of DBUS_TYPE_UINT32.
> > Depending on how the demarshaller is
> > implemented this type change is potentially handled automatically.
This is probably not the case for whatever C and C++ implementations
there might exist.
> > Extending the DBus interface (instead of just changing the
> > signature) is easy enough.
>
> Okay, sounds reasonable to me. I don't have a problem with this.
In order not to confuse anybody, at a minimum the new DBUS_TYPE_UINT64s
must be given a new name. Unfortunately as the API has not been marked
experimental we'll have to support the current wrap-around prone
DBUS_TYPE_UINT32s also...
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
