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