Hi Marcel/Lizardo,
On Aug 10, 2011, at 9:26 PM, Marcel Holtmann wrote:
Hi Anderson,
The advertising report event has the 'Length' field to inform the
'Data' field length, so I believe it has a variable length.
According to its description, the 'Length' field may vary from 0x00
to 0x1F (31) bytes.
You are right. Although the section 11 gives the impression the size
is always 31, this is not what happens on actual hardware, which
usually sends only the significant bytes (and the length is know from
the "Length" field.
The only drawback I see so far is copying extra ~200 bytes each time
we get a advertising report data.
I agree. If this event is being sent on each adv. data report event,
it will be more than 6 times the amount of data (with non-significant
bytes containing only zeroes) sent to userspace.
if we wanna save bytes copied and send to userspace, then we might
even
fix this for BR/EDR. Since while it is fixed there only a fraction is
used there most of the times.
IMO changing the struct device_found is another issue (this would
require userspace changes too).
The point in adding the eir_len parameter is to avoid:
* preparing (memset and copy EIR from adv report) a 240-bytes
temporary buffer to pass to mgmt_device_found()
* to memcpy() ~200 useless bytes to ev.eir in mgmt_device_found()
For each advertising data we gather from the LE scan (which can be
a lot) we would need to do that.
BR,
Andre.
--
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
