_X_EXPORT'ing x_rpcbuf_write_CARD8s() just for internal use (eg. glx),
it's *NOT* supposed to be called by any external modules/drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
_X_EXPORT'ing some x_rpcbuf_clear() and x_rpcbuf_write_CARD8s() just for
internal use (eg. glx) - those are *NOT* supposed to be called by any
external modules/drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of always zero'ing out the whole buffer at allocation time, only
do it where really necessary. Also adding x_rpcbuf_reserve0() for reserving
buffer space that's explicitly cleared.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both are the same types, the `struct x_rpcbuf` still remains, but it
seems more clear to use the `x_rpcbuf_t` as the canonical name.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The existing x_rpcbuf_write_string() function is just writing the string w/o
trailing zero. It's for cases where the string length is known by other means
(eg. some header field). In cases where we also need the trailing zero written
(eg. when sending lists of strings) this isn't sufficient.
Thus introducing another variant of this function, which is always writing
a leading zero. Using this one, the string's characters will be followed
by 1, 2 or 3 zeros (and also be 32bit aligned)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
when the err_clear flag is set, the buffer memory will automatically
be free()ed when allocation failed. This allows simplificatoin of
caller's error pathes: the caller doesn't need to to call x_rpcbuf_clear()
anymore and eg. can directly return out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Remember allocation failure in new `error` field, for easing error
handling in complex callers: those now don't need to check each single
return value, but can (try to) continue their normal operation and
check for error condition later.
For example we can turn this:
for (....) {
if (!x_rpcbuf_write_CARD16(&rpcbuf,...)) {
[ various cleanups ]
return BadAlloc;
}
if (!rpcbuf_write_CARD8s(&rpcbuf,...)) {
[ various cleanups ]
return BadAlloc;
}
[ more of this ]
}
...
Into:
for (....) {
x_rpcbuf_write_CARD16(&rpcbuf,...));
x_rpcbuf_write_CARD8s(&rpcbuf,...));
[ more of this ]
}
...
if (&rpcbuf->error) {
[ various cleanups ]
return BadAlloc;
}
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since so many request handlers have to assemble complex reply payloads,
we've got a lot complexity on counting the needed space and filling in
the data into the right places.
Thus adding a little dynamic buffer structure, where one just can append
data arbitrarily. The buffer will automatically allocate memory as-needed
and finally leave everything in a big memory block for later write-out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
