From: Johannes Berg <johannes@sipsolutions.net>
To: Javier Lopez <jlopex@gmail.com>
Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com, j@w1.fi,
javier@cozybit.com
Subject: Re: [PATCH v4] mac80211_hwsim driver support userspace frame tx/rx
Date: Thu, 19 May 2011 09:00:28 -0700 [thread overview]
Message-ID: <1305820828.8237.10.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1305149577-2636-1-git-send-email-jlopex@gmail.com> (sfid-20110511_233323_840596_E9B7F988)
Hi,
Sorry for the late reply, I was travelling and had so much other stuff
to do as well. I like what you did with the pending, but have some
further comments:
> + /* We get the flags for this transmission, wmediumd maybe
> + changes its behaviour depending on the flags */
> + NLA_PUT_U32(skb, HWSIM_ATTR_FLAGS, info->flags);
I'm not sure that we want to tie wmediumd to a precise version of
mac80211? This would make the mac80211 internals ABI for wmediumd rather
than API for the drivers, which I'd like to avoid. What flags does it
actually need? I think you should translate those flags into hwsim
netlink flags.
> + /* We get the tx control (rate and retries) info*/
> + NLA_PUT(skb, HWSIM_ATTR_TX_INFO,
> + sizeof(struct ieee80211_tx_rate)*IEEE80211_TX_MAX_RATES,
> + info->control.rates);
The same applies here, Felix is indeed planning to change this. I know
it's a lot of code and not very efficient, but I think you should wrap
this stuff in a real netlink attribute so it has a chance of not
breaking when mac80211 APIs change.
> + /* We create a cookie to identify this skb */
> + NLA_PUT_U32(skb, HWSIM_ATTR_COOKIE, (unsigned long) my_skb);
This needs to be a U64 so that 64-bit systems work.
> +static bool mac80211_hwsim_tx_frame(struct ieee80211_hw *hw,
> + struct sk_buff *skb)
> +{
> + if (atomic_read(&wmediumd_pid)) {
This reminds me -- why is that thing atomic? It doesn't seem necessary
since there will be locking (rtnl) on the callbacks setting it anyway?
> @@ -571,6 +671,7 @@ static void mac80211_hwsim_tx(struct ieee80211_hw *hw, struct sk_buff *skb)
> if (!(txi->flags & IEEE80211_TX_CTL_NO_ACK) && ack)
> txi->flags |= IEEE80211_TX_STAT_ACK;
> ieee80211_tx_status_irqsafe(hw, skb);
> +
> }
spurious whitespace change
> @@ -650,7 +751,6 @@ static void mac80211_hwsim_beacon_tx(void *arg, u8 *mac,
>
> mac80211_hwsim_monitor_rx(hw, skb);
> mac80211_hwsim_tx_frame(hw, skb);
> - dev_kfree_skb(skb);
> }
Where are frames freed in the no-wmediumd case?
> @@ -966,12 +1066,9 @@ static int mac80211_hwsim_ampdu_action(struct ieee80211_hw *hw,
>
> static void mac80211_hwsim_flush(struct ieee80211_hw *hw, bool drop)
> {
> - /*
> - * In this special case, there's nothing we need to
> - * do because hwsim does transmission synchronously.
> - * In the future, when it does transmissions via
> - * userspace, we may need to do something.
> - */
> + /* Let's purge the pending queue */
> + struct mac80211_hwsim_data *data = hw->priv;
> + skb_queue_purge(&data->pending);
> }
This doesn't seem right, but unless you do buffering in wmediumd you
don't really have to worry much. I guess a real implementation would
send a notification to wmediumd to flush and then wait for the queue to
become empty (with some timeout I guess).
> + if (!_found) {
> + printk(KERN_DEBUG "mac80211_hwsim: invalid radio ID\n");
> + return NULL;
> + }
I think you're generally erring a bit on the side of too much debug
printing, but since it's a debug driver I don't really care :)
> + return data;
> +}
> +
> +static int hwsim_tx_info_frame_received_nl(struct sk_buff *skb_2,
> + struct genl_info *info)
> +{
> +
> + struct ieee80211_hdr *hdr;
> + struct mac80211_hwsim_data *data2;
> + struct ieee80211_tx_info *txi;
> + struct ieee80211_tx_rate *tx_attempts;
> + struct sk_buff __user *ret_skb;
> + struct sk_buff *skb = NULL, *tmp;
> +
> + int i;
> + bool found = false;
> +
> + struct mac_address *dst = (struct mac_address *)nla_data(
> + info->attrs[HWSIM_ATTR_ADDR_TRANSMITTER]);
> + int flags = nla_get_u32(info->attrs[HWSIM_ATTR_FLAGS]);
Maybe I'm missing it, but I don't see where you verified that the
attributes actually exist? This might otherwise crash. Same for other
attributes too.
> + ret_skb = (struct sk_buff __user *)
> + (unsigned long) nla_get_u32(info->attrs[HWSIM_ATTR_COOKIE]);
Like this one, also u64.
> + tx_attempts = (struct ieee80211_tx_rate *)nla_data(
> + info->attrs[HWSIM_ATTR_TX_INFO]);
Again, translation between structs and netlink would be good so we don't
tie this to internal mac80211 APIs.
> + if (tx_attempts == NULL)
> + goto out;
That can never happen ... either nla_data() already crashed because the
attribute didn't exist, or tx_attempts is non-NULL. However, you need to
check nla_len().
johannes
next prev parent reply other threads:[~2011-05-19 15:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-18 20:45 [PATCH] mac80211_hwsim driver support userspace frame tx/rx Javier Lopez
2011-04-19 2:19 ` Javier Cardona
2011-04-22 19:31 ` [PATCH v2] " Javier Lopez
2011-04-28 18:34 ` John W. Linville
2011-05-01 19:29 ` [PATCH v3] " Javier Lopez
2011-05-01 21:35 ` Johannes Berg
2011-05-11 21:32 ` [PATCH v4] " Javier Lopez
2011-05-18 0:09 ` Javier Cardona
2011-05-18 20:58 ` Johannes Berg
2011-05-19 16:00 ` Johannes Berg [this message]
2011-05-25 10:41 ` [PATCH v5] " Javier Lopez
2011-05-25 19:03 ` [PATCH v6] " Javier Lopez
2011-05-26 3:54 ` Johannes Berg
2011-05-31 21:29 ` [PATCH v7] " Javier Lopez
2011-05-31 22:06 ` Javier Lopez
2011-06-01 4:16 ` Johannes Berg
[not found] ` <BANLkTinE0axwc_X9Gt=qdrjufopvPNADng@mail.gmail.com>
2011-06-01 8:48 ` Johannes Berg
2011-06-01 9:26 ` [PATCH v8] " Javier Lopez
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=1305820828.8237.10.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=j@w1.fi \
--cc=javier@cozybit.com \
--cc=jlopex@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/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).