> > > > As for the "experimental" BT_POLL_ERRQUEUE. This is an addition to the > > > > ABI, right? So immutable. Is it fair to call that experimental? > > > > > > I guess you are referring to the fact that sockopt ID reserved to > > > BT_POLL_ERRQUEUE cannot be reused anymore even if we drop its usage in > > > the future, yes that is correct, but we can actually return > > > ENOPROTOOPT as it current does: > > > > > > if (!bt_poll_errqueue_enabled()) > > > return -ENOPROTOOPT > > > > I see. Once applications rely on a feature, it can be hard to actually > > deprecate. But in this case it may be possible. > > > > > Anyway I would be really happy to drop it so we don't have to worry > > > about it later. > > > > > > > It might be safer to only suppress the sk_error_report in > > > > sock_queue_err_skb. Or at least in bt_sock_poll to check the type of > > > > all outstanding errors and only suppress if all are timestamps. > > > > > > Or perhaps we could actually do that via poll/epoll directly? Not that > > > it would make it much simpler since the library tends to wrap the > > > usage of poll/epoll but POLLERR meaning both errors or errqueue events > > > is sort of the problem we are trying to figure out how to process them > > > separately. > > > > The process would still be awoken, of course. If bluetoothd can just > > be modified to ignore the reports, that would indeed be easiest from > > a kernel PoV. > > @Pauli Virtanen tried that but apparently it would keep waking up the > process until the errqueue is fully read, maybe we are missing > something, or glib is not really doing a good job wrt to poll/epoll > handling. Perhaps this is because poll is level triggered. Maybe epoll in edge triggered mode would avoid re-waking for the same outstanding events.
