Return-Path: Message-ID: <4F84A422.3030900@sipsolutions.net> Date: Tue, 10 Apr 2012 14:20:34 -0700 From: Johannes Berg MIME-Version: 1.0 To: Marcel Holtmann CC: Andrei Emeltchenko , linux-bluetooth@vger.kernel.org, linux-wireless@vger.kernel.org Subject: Re: [RFCv1] mac80211: Adds Software / Virtual AMP 80211 References: <1334059909-20513-1-git-send-email-Andrei.Emeltchenko.news@gmail.com> <1334059909-20513-2-git-send-email-Andrei.Emeltchenko.news@gmail.com> (sfid-20120410_141120_556160_FD038CE7) <4F846257.1060807@sipsolutions.net> <1334092668.16897.54.camel@aeonflux> In-Reply-To: <1334092668.16897.54.camel@aeonflux> Content-Type: text/plain; charset=UTF-8; format=flowed List-ID: >> 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. > > adding AMP (meaning Bluetooth Alternate MAC/PHY in case anybody cares) > for SoftMac WiFi cards should be done solely in kernel space between > Bluetooth core and mac80211. All the FullMac cards will expose the HCI > AMP directly via the Bluetooth core. See Marvell solution for example. > > If we require a userspace interaction, I think we are doing something > wrong here. And as far as I can tell, the only tricky part is the WPA2 > PSK 4-way handshake. We would need a kernel implementation for that. You already know I disagree, I don't want this code re-implemented in kernel space when adding a few tightly controlled APIs is all it needs to use an existing implementation of the relevant mechanisms. johannes