lbs_cmd_with_response() buffer sizes
Holger Schurig
hs4233 at mail.mn-solutions.de
Mon Dec 17 02:55:55 EST 2007
> Also, I think we have them the wrong way round. Most of the
> time, sizeof() is going to give you the total size of the
> object that the compiler knows about -- which is suitable for
> the _response_ size, although the packet you send may be
> smaller. So if we're going to explicitly specify one or the
> other, it should be the _outgoing_ size we specify. I'll poke
> at it later; in the middle of the core command
> queueing stuff now.
We have to basically deal with three sizes:
1. the size of the command
a) mostly determined via sizeof()
b) however there are some commands that can
take TLVs, so you cannot always use sizeof()
2. the size of the response buffer
a) again many responses just return a fixed record,
so sizeof() would be ok for them
b) but a bunch of responses return variable-length
data, so we need to tell how much bytes at most
our (void*) response buffer can hold
3. the actual size of the response
In the case of 2b, it's important for the caller
of a commands with a variable-length response to know
how much bytes the firmware sent him.
So-to-speak, a command size is a in-parameter for lbs_cmd(), and
response size is an in-out-parameter for lbs_cmd(). I used an
int* for the latter, at the exponse of having an explicit
int rsp_size = XXXX; /* sizeof() or constant */
lbs_cmd(..., cmd_size, ..., &rsp_size);
So the additional rsp_size variable was a bit annoying to type,
but that interface covered all possibilities.
More information about the libertas-dev
mailing list