Hi Chen, >>>>> So at present, in kernel part, we can only say the original authors >>>>> intended to do like this. And only within kernel part, it can not cause >>>>> issue. I guess, original authors originally knew what we talk about. >>>> >>>> I've just searched for hci_u*filter it is all horrid. >>>> Look at the code for get/set_sockopt of HCI_FILTER. >>>> Someone seems to have done a complete 'bodge job' of fixing the user >>>> interface >>>> for apps (32bit and 64bit) on 64bit kernels. >>> >>> we are actually fully aware of that. Just keep in mind that this code is >>> from 2.4.6 kernel and with >>> that most likely 14 years old by now. Unfortunately it ended up as >>> userspace API. >> >> AFAICT the userspace API is always __u32[2] the long[2] is never exposed >> to userspace (certainly not through the socket option code). >> >> Quite why all the casts were added - instead of changing the type >> is probably hidden in the annals of the source repo. >> Some serious archaeology might be in order. >> > > For me, I guess what you said above sounds reasonable. But excuse me, > I am not familiar with the related modules outside Linux kernel (at > present, it is out of my border). > > I guess, I am not the suitable member to make the related fix patch for > this issue. Welcome any other members to send the fix patch for it. > > And for me, if "hci_u*filter" is related with the modules outside kernel > (I guess, it should be), I recommend to put it to the related "uapi" > header.
since that is such old code, the "uapi" is essentially what we have as libbluetooth from the BlueZ userspace code. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
