| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
Also made it return directly a pointer to the raw data buffer.
|
| |
|
|
|
|
|
|
| |
The contents of the input buffer are never modified when reading variables from
it, so better use a constant pointer in the methods doing it.
What it does change is the pointer to the current position in the constant
buffer.
|
| |
|
|
|
|
|
| |
If we get an error parsing a JSON file we really want to have the exact line
number where the error happened, so don't just skip the comment lines and
substitute them with an empty line instead so that the line numbers don't
change.
|
| |
|
|
|
|
|
|
|
| |
For those variables which are containers of other variables (struct, sequence
and array), ensure we call `emit_helper_methods()' in order to generate variable
specific dispose() helpers and such.
This fixes the case of nested arrays of structs (arrays of structs with arrays of
structs whithin).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'length-prefix-size'
Use the new 'size-prefix-format' property to specify whether the length prefix
variable is a 'guint8' or a 'guint16'.
We therefore consolidate the way how this length prefix variable is specified in
both arrays and strings.
So, instead of:
"length-prefix-size" : "16"
We now just do:
"size-prefix-format" : "guint16"
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'array-size' property was used to define an implicit variable to be found at
the beginning of every array. This property expected a dictionary with one
single 'format' key.
Instead of this setup, create a new 'size-prefix-format' property which directly
expects the format string of the variable to be used as array-length indicator.
So, instead of:
"array-size" : { "format" : "guint16" }
We can now just use:
"size-prefix-format" : "guint16"
Also, remove the explicit size definitions when the format is "guint8", as that
is the default already when none specified and the array is not of fixed size.
|
| | |
|
| | |
|
| |
|
|
| |
The contents of the containers were not being freed properly.
|
| |
|
|
| |
Including "PDS Reset".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Like these:
struct {
uint8 num_instances;
struct {
uint8 length;
char data[];
};
};
|
| |
|
|
| |
Like IPv6 addresses.
|
| |
|
|
|
| |
Most string lengths are UINT8, but some (WDS Get Current Settings
PCSCF Domain Name List, for example) are UINT16.
|
| |
|
|
| |
Including "WMS Reset".
|
| |
|
|
|
|
|
| |
If 'max-size' is given for an output string variable, we will read up to the
specified number of bytes from the buffer. This will help us handle cases where
the firmware of the device doesn't match what it sends with what it wanted to
send (e.g. IMEI longer than 15 characters).
|
| | |
|
| |
|
|
|
|
| |
The service-specific implementation header needs to include only the raw
enums/flags headers; while the source needs to include the enum/flags types
headers.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
TLVs are either input or output, not always output.
|
| |
|
|
|
|
| |
If the 'version' tag is given in the messages and the `QmiDevice' is opened with
a explicit version info check, we will return an error if we're trying to send
a message which was introduced in a newer version of a service we support.
|
| | |
|
| |
|
|
|
| |
The Variable-specific setter implementation may include some validity checks, so
it may happen that instead of setting the variable an error is emitted.
|
| | |
|
| | |
|
| |
|
|
|
| |
This property specifies how the size prefix of the array is read; it will be
'guint8' by default if none explicit given.
|
| |
|
|
|
| |
They will still be read into a new heap-allocated string, but we now control
whether the user gives a proper size.
|
| |
|
|
|
|
| |
String variables with the 'fixed-size' configuration will not require additional
heap allocations, they will be included directly in the input/output bundle
structure.
|
| | |
|
| |
|
|
|
| |
The code generator can now handle uints of arbitrary sizes (<= guint64), which
are read into guint64 variables.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Bumped required glib version to 2.32. Actually... there is no real issue with
keeping 2.28 as minimum required version, as for now there's no array element
which requires clearing, but anyway, given that QMI is to be used in quite
recent kernels, it shouldn't be a big issue to require a recent glib as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `sequence' variable types are defined in the same way as `struct' types, but
the generated implementation is completely different:
* Struct TLVs will generate public struct types, and the getter/setter methods
will pass a single variable of that new struct type.
* Sequence TLVs will not generate any new public nor private type. The getter
and setter methods will pass N items, one for each member of the sequence.
It should be safe to do so and maintain API/ABI compatibility afterwards, as
existing TLVs are not expected to change.
|
| |
|
|
| |
And change the structs to be passed by reference.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a huge refactor to avoid using internal packed structs to match TLVs
from a raw byte buffer. There are cases where packed structs do not help, for
example when two variable-length fields (like strings) are found in the same
TLV.
Instead of packed structs, we'll read basic types one by one directly from the
raw byte buffer. With this new logic, struct and array variables are no more
than containers of other basic types. Each basic type, implemented as objects
inheriting from a base Variable type, knows how to read/write from/to the
raw buffer. Therefore, reading a struct is just about reading one by one each
of the fields in the struct; and reading an array is just about providing a
loop to read all the array elements one by one.
This greatly simplifies reading basic types like integers, as the implementation
is kept in a single place, regardless of having the integer as the only field
in the TLV or as a field of a struct TLV or as an element of an array TLV.
Strings are treated a bit differently. In string TLVs, the string is to be
considered to be as long as the TLV value itself. In struct TLVs with string
fields, the string is assumed to have a 1-byte length prefix which specifies
the length of the string field within the TLV.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
