Hi Johan,
On Wed, Jan 18, 2012 at 4:29 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote:
> Hi Lizardo,
>
> On Wed, Jan 18, 2012, Anderson Lizardo wrote:
>> Hi Johan,
>>
>> On Wed, Jan 18, 2012 at 2:51 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote:
>> > +static inline u16 eir_append_data(u8 *eir, u16 eir_len, u8 type, u8 *data,
>> > + u16 data_len)
>> > +{
>> > + eir[eir_len++] = sizeof(type) + data_len;
>>
>> Isn't it better to have data_len as u8? It is impossible for a EIR or
>> AD entry to have more than 255 octets (given the length field is one
>> octet).
>
> Since we've taken up the habit of appending items to the data (such as
> the device class) before passing it on to user space we thought it'd be
> more future proof to use two octets. The mgmt messages use two octets as
> well. I was also initially of the opinion that one should be enough but
> Marcel convinced me that two is better since we're living very close to
> the limit and would have to break the API if at any point in the future
> we suddenly need more space.
While for mgmt it is ok to use two octets (I was aware of this
rationale), I was referring more specifically to the snippet above,
where you copy a u16 value to a u8 eir[] entry.
While you can append many EIR fields (and thus have a local EIR blob
with total size greater than you would normally send over the air),
each EIR field you append is still limited to 255 bytes as per spec.
This means it is okay on the function above to "eir_len" be u16, but I
think "data_len" is not.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
