Hi Andre, > >>> 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). personally I break this one now, instead of later. > 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. And the same applies to BR/EDR actually. It is just that we never really encounter lot of inquiry results (except UPF), but it is the same problem that we end up copying data around for no good reason. If we wanna optimize this, then we better do it for both. So we have the same handling towards userspace. Regards Marcel -- 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
