Hi Johannes, On Tue, Apr 17, 2012 at 07:07:21PM -0700, Johannes Berg wrote: > > > > >> I don't get this patch at all. Why am I reviewing some very very basic > > > > >> skeleton code when we should be discussing userspace APIs (we have > > > > >> already discussed them with a few people years ago), how the AMP is > > > > >> going to be managed, how the security handshake is going to work, etc. > > > > Do we have some outcome from that discussion? > > This API-defining patch is probably the best we have: > http://johannes.sipsolutions.net/patches/kernel/all/2010-10-13-15% > 3a24/035-bt3-amp.patch Thanks for the link. After looking to the patches I think that there are some similarities with respect to interface type. As I understood the basic idea is the same: create virtual interface. But in your case the implementation is really difficult. Why do we need netlink commands like NL80211_CMD_HCI_AMP_ADD and NL80211_CMD_HCI_AMP_DELETE if what we need is to create/delete virtual interface which can be done with standard tools with a several lines patch to iw: <------8<--------------------------------------------------------------------- | diff --git a/interface.c b/interface.c | index 6c90f9d..49227ce 100644 | --- a/interface.c | +++ b/interface.c | @@ -136,6 +136,9 @@ static int get_if_type(int *argc, char ***argv, enum | nl80211_iftype *type, | } else if (strcmp(tpstr, "__p2pgo") == 0) { | *type = NL80211_IFTYPE_P2P_GO; | return 0; | + } else if (strcmp(tpstr, "vamp") == 0) { | + *type = NL80211_IFTYPE_VIRTUAL_AMP; | + return 0; | } | | fprintf(stderr, "invalid interface type %s\n", tpstr); | diff --git a/nl80211.h b/nl80211.h | index e474f6e..ad4a252 100644 | --- a/nl80211.h | +++ b/nl80211.h | @@ -1546,6 +1546,7 @@ enum nl80211_iftype { | NL80211_IFTYPE_MESH_POINT, | NL80211_IFTYPE_P2P_CLIENT, | NL80211_IFTYPE_P2P_GO, | + NL80211_IFTYPE_VIRTUAL_AMP, | | /* keep last */ | NUM_NL80211_IFTYPES, | diff --git a/util.c b/util.c | index 103ded9..bf2fefe 100644 | --- a/util.c | +++ b/util.c | @@ -132,6 +132,7 @@ static const char *ifmodes[NL80211_IFTYPE_MAX + 1] = { | "mesh point", | "P2P-client", | "P2P-GO", | + "Virtual AMP", | }; | | static char modebuf[100]; | <------8<--------------------------------------------------------------------- Anyway I think that this is not an issue since those commands can be easily added. > > > The whole AMP control goes via A2MP and L2CAP and both are fully > > > implemented inside the kernel. In theory we do not even need to expose > > > HCI AMP interfaces to userspace. > > > > Johannes, you can think of SoftAMP as analog of SoftMAC (vs FullMAC). > > SoftMAC is also possible to implement in user space but only > > authentication is done this way. > > Yeah, and we also implement roaming and crypto stuff in userspace, for > softmac. Heck, we implement crypto in userspace even for fullmac, so > really ... Does crypto stuff mean getting symmetric key? I see that all commands by default are sent via netlink to wpa_supplicant. I think that we can send those command which cannot be handled by us directly but I believe most command might be handled directly. > > Consider use case when user sends data over Bluetooth High Speed. Data > > go from obex user space to kernel L2CAP. Then you just need to add > > MAC header and send to wireless device. But you are proposing to copy data > > to user space for processing; then user space needs to copy data again to > > kernel and then to wireless device. > > I never said data should be copied. If you thought I did, you > misunderstood me. I see now that data are sent directly through ieee80211_tx_skb and received through ieee80211_deliver_skb. BTW: Have you tested those patches? Best regards Andrei Emeltchenko -- 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
