Re: [PATCH 07/15] Bluetooth: Merge device class into the EIR data in mgmt_ev_device_found

Hi Lizardo,

On Wed, Jan 18, 2012, Anderson Lizardo wrote:

quoted

quoted

On Wed, Jan 18, 2012 at 2:51 PM, Johan Hedberg [off-list ref] wrote:

quoted

+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.

Yes, you're completely right (and I should have paid more attention to
what exactly you were referring to). I'll fix it.

Johan