Alright, let me try to summarise what we want as API for DLS: * NL80211_CMD_GET_DLS_PEER doit: simple boolean answer: is DLS set up with given peer? dump: give all DLS peers * NL80211_CMD_SET_DLS_PEER [_CMD_REQUEST_DLS] request setup of DLS * NL80211_CMD_NEW_DLS_PEER kernel notification about a newly setup DLS connection * NL80211_CMD_DEL_DLS_PEER [_CMD_TEARDOWN_DLS] request teardown of DLS connection * NL80211_CMD_NEW_DLS_REQUEST kernel notification for DLS request from the other side * NL80211_CMD_SET_DLS_REQUEST send DLS response to given peer with given status (* NL80211_CMD_GET_DLS_REQUEST * NL80211_CMD_DEL_DLS_REQUEST make no sense) I tried ordering these by get/set/new/del quads as David suggested but I don't think it makes sense for DLS request, I suppose we have somewhat different requirements and I think I'd rather have different names as in brackets above. Then again, that could get confusing with _CMD_REQUEST_DLS and _CMD_NEW_DLS_REQUEST... For me, that settles the DLS API. That API is easily implementable by the userspace MLME as well. Now, for TS, it seems that most of the work is with handling the response to an ADD TS request. Also, the current code doesn't seem to allow using TCLAS or TCLAS processing information for the ADDTS request frame. For the response, I suppose you'll be adding it, but I'm not sure we want to have all the complexity for the request. Maybe we should simply require the ADDTS/DELTS request frames to be injected and we handle the responses with some notifications via nl80211? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
