From: Alexander Wetzel <alexander@wetzel-home.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v3 03/12] mac80211: IEEE 802.11 Extended Key ID support
Date: Fri, 1 Mar 2019 21:43:43 +0100 [thread overview]
Message-ID: <95ba87e8-d7d2-53ae-f2c8-d4656dc1d29a@wetzel-home.de> (raw)
In-Reply-To: <767ada740d984e180d0ac799487722293a50367c.camel@sipsolutions.net>
>>> So here the reasoning for why I named them as they are and why I prefer
>>> the names used in the patch.
>>> First, many drivers will handle SET_KEY and SET_KEY_RX_ONLY with the
>>> same code and not differentiate between those at all. Using EXT_as a
>>> prefix for the "normal" command is therefore a nice way to imply the
>>> command can only be used with Extended Key ID and still link it to the
>>> original command.
>>> But more important for me was the clash between what the command spells
>>> and what it does in the COMPAT mode: SET_KEY_RX_ONLY would then be used
>>> to install a TX only key which never can be used by the card for Rx.
>>> So I decided to rename it to EXT_SET_KEY, just indicating that this
>>> command adds a new key to the card for Extended Key ID and drop the
>>> confusing reference to Rx.
> Wait, what? In compat mode SET_KEY_RX_ONLY installs a TX-only key? Ah,
> you mean before you changed this.
>
> Why don't we split out compat mode then?
>
> But I see where you're coming from with the EXT_ now. I need to think of
> it less as an "extension" now, but as "extended key ID". I'm not really
> entirely sure that makes sense - even what we think of as "extended key
> ID" now might be the new normal soon? But then again the spec does the
> same thing.
>
>>> Long story short: Using SET_KEY_RXONLY and SET_KEY_TX is not wrong, but
>>> I would rate them more confusing.
> Fair enough.
I've had second (or more like tenths..) thoughts about this API.
If you like any of the solutions below more than the others I'll use
that in the next patch, of course...
In a nutshell, the point of EXT_SET_KEY is to install a key, prepare it
for Tx but NOT use it for Tx. The driver can use it for Rx (NATIVE) or
just do nothing with the (in COMPAT mode) Tx only key till mac80211
starts using it for Tx later.
1) Assuming we keep the RX_ONLY key flag we could just drop EXT_SET_KEY
and use the "normal" SET_KEY with the flag moved to ieee80211_key_conf.
We really just want to install the key to the driver here, only drivers
like ath10k need a way to figure out it must not be used for Tx.
2) We also can drop the Rx only flag/extra command and simply use
SET_KEY. ath10k will then have to honor the keyID mac80211 prepared when
it want to support Extended Key ID. (ath10k seems to need a firmware
update either way, so that could be acceptable.)
That said I've now decided to simply name the calls in the next patch:
SET_KEY
-> no RX only flag!
SET_KEY_RX
-> SET_KEY, only key must not be used for Tx
DISABLE_KEY,
-> unchanged
ACTIVATE_KEY
-> so far named EXT_KEY_RX_TX
DISABLE_KEY_RX
-> so far named EXT_DISABLE_KEY_RX
We can then continue the discussion with a new patch and the other fixes
in it when needed.
To really clean that up we would have to change the existing names to
something like ADD_KEY, REMOVE_KEY. We could then name the new calls
ADD_KEY_RX, ACTIVATE_KEY and DISABLE_KEY_RX. But that seems to be overkill.
Alexander
Alexander
next prev parent reply other threads:[~2019-03-01 20:43 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-10 21:06 [RFC PATCH v3 00/12] Draft for Extended Key ID support Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 01/12] mac80211: Optimize tailroom_needed update checks Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 02/12] nl80211/cfg80211: Extended Key ID support Alexander Wetzel
2019-02-15 10:52 ` Johannes Berg
2019-02-17 19:19 ` Alexander Wetzel
2019-02-22 8:30 ` Johannes Berg
2019-02-22 23:04 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 03/12] mac80211: IEEE 802.11 " Alexander Wetzel
2019-02-15 11:06 ` Johannes Berg
2019-02-19 20:58 ` Alexander Wetzel
2019-02-21 19:47 ` Alexander Wetzel
2019-02-22 8:41 ` Johannes Berg
2019-02-23 21:02 ` Alexander Wetzel
2019-03-01 20:43 ` Alexander Wetzel [this message]
2019-02-23 17:26 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 04/12] mac80211: Compatibility " Alexander Wetzel
2019-02-15 11:09 ` Johannes Berg
2019-02-21 20:07 ` Alexander Wetzel
2019-02-22 8:53 ` Johannes Berg
2019-02-23 22:50 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 05/12] mac80211: Mark A-MPDU keyid borders for drivers Alexander Wetzel
2019-02-15 11:50 ` Johannes Berg
2019-02-21 21:20 ` Alexander Wetzel
2019-02-22 8:51 ` Johannes Berg
2019-02-23 21:47 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 06/12] mac80211_hwsim: Ext Key ID support (NATIVE) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 07/12] iwlwifi: Extended " Alexander Wetzel
2019-02-15 11:52 ` Johannes Berg
2019-02-22 20:50 ` Alexander Wetzel
2019-02-22 21:06 ` Johannes Berg
2019-02-24 13:04 ` Alexander Wetzel
2019-04-08 20:10 ` Johannes Berg
2019-04-10 20:46 ` Alexander Wetzel
2019-04-12 9:51 ` Johannes Berg
2019-04-14 16:12 ` Alexander Wetzel
2019-04-15 8:44 ` Johannes Berg
2019-04-15 20:09 ` Alexander Wetzel
2019-04-16 9:31 ` Johannes Berg
2019-04-16 18:28 ` Alexander Wetzel
2019-04-16 19:11 ` Johannes Berg
2019-04-16 21:32 ` Alexander Wetzel
2019-04-12 11:19 ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 08/12] iwlwifi: dvm - EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:54 ` Johannes Berg
2019-02-22 21:15 ` Alexander Wetzel
2019-02-22 21:20 ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 09/12] ath: Basic Extended Key ID support (COMPAT+NATIVE) Alexander Wetzel
2019-02-13 11:05 ` Kalle Valo
2019-02-13 23:15 ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 10/12] ath5k: ath_key_config() API compatibility update Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 11/12] ath9k: Extended Key ID support (COMPAT) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 12/12] ath9k: EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:10 ` [RFC PATCH v3 00/12] Draft for Extended Key ID support Johannes Berg
2019-02-21 20:44 ` Alexander Wetzel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=95ba87e8-d7d2-53ae-f2c8-d4656dc1d29a@wetzel-home.de \
--to=alexander@wetzel-home.de \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).