From: Johannes Berg <johannes@sipsolutions.net>
To: Rostislav Lisovy <lisovy@gmail.com>
Cc: "John W. Linville" <linville@tuxdriver.com>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Michal Sojka <sojkam1@fel.cvut.cz>,
s.sander@nordsys.de, jan-niklas.meier@volkswagen.de,
Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
Subject: Re: [RFC 2/2] mac80211: Add new interface type for OCB mode
Date: Mon, 19 May 2014 16:57:23 +0200 [thread overview]
Message-ID: <1400511443.4273.16.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <1400510945-24868-3-git-send-email-rostislav.lisovy@fel.cvut.cz> (sfid-20140519_164915_803287_21439779)
On Mon, 2014-05-19 at 16:49 +0200, Rostislav Lisovy wrote:
> include/uapi/linux/nl80211.h | 3 ++
> net/mac80211/Makefile | 3 +-
> net/mac80211/cfg.c | 1 +
> net/mac80211/chan.c | 2 +
> net/mac80211/driver-ops.h | 3 +-
> net/mac80211/ieee80211_i.h | 38 ++++++++++++++
> net/mac80211/iface.c | 28 +++++++++++
> net/mac80211/ocb.c | 115 +++++++++++++++++++++++++++++++++++++++++++
> net/mac80211/util.c | 5 ++
> net/wireless/util.c | 1 +
please avoid patches that modify both cfg80211 and mac80211 unless
they're really small.
> +/**
> + * struct ieee80211_if_ocb - the specific struct for ocb-mode
> + *
> + * In this struct all ocb-specific information of an interface is stored.
> + *
> + * @timer: the timer used for all tasks in the ocb-code
Why do you need your own timer?
> + * @work: holds the workqueue
and work struct (not a workqueue - that's something entirely different)?
we have a general interface work struct.
> + * @skb_queue: holds all queued skb to be processed
Why do you need to queue SKBs?
> + * @wrkq_flags: bitmask telling what work is pending
> + * @timer_running: tells if the timer is running
> + * @bssid: holds the BSSID (IEEE802.11p defines this to be
> + * ff:ff:ff:ff:ff:ff but this is more flexible)
Why would you ever need this flexibility? It seems pointless to prepare
for it - I'm guessing you're never going to implement it?
> @@ -622,6 +632,17 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
>
> if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE)
> changed |= ieee80211_reset_erp_info(sdata);
> +
> + if (sdata->vif.type == NL80211_IFTYPE_OCB) {
> + /* Disable beacons */
> + sdata->vif.bss_conf.enable_beacon = false;
> + changed |= BSS_CHANGED_BEACON;
> +
> + /* Receive all data frames */
> + local->fif_other_bss++;
> + ieee80211_configure_filter(local);
> + }
NACK. Please make a proper "join OCB" operation etc. In the wireless
stack, "ifup" shouldn't be used to start real operation.
> +/**
> + * ieee80211_ocb_housekeeping - Housekeeping function (expires stations)
> + *
> + * @sdata:
> + * @ifocb:
yes?
> + * This function is used for all periodical clean up work.
> + * It expires all stations that have not shown up for a given period of time.
> + * After all cleanups have been done it schedules the next run.
> + */
> +static void ieee80211_ocb_housekeeping(struct ieee80211_sub_if_data *sdata,
> + struct ieee80211_if_ocb *ifocb)
> +{
> + ieee80211_sta_expire(sdata, IEEE80211_OCB_PEER_INACTIVITY_LIMIT);
> + mod_timer(&ifocb->timer,
> + round_jiffies(jiffies + IEEE80211_OCB_HOUSEKEEPING_INTERVAL));
> +}
use a delayed work struct?
I don't even see a call to turn on the carrier?
Anyway I think you should have some OCB join method in the cfg80211 API
even if there's nothing really to do... at minimum, you need to specify
a channel somehow!
johannes
prev parent reply other threads:[~2014-05-19 14:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-19 14:49 [RFC 0/2] mac80211: Add new interface type for OCB (Outside the Context of a BSS) mode Rostislav Lisovy
2014-05-19 14:49 ` [RFC 1/2] cfg80211: Add channel flags limiting availability to OCB mode only Rostislav Lisovy
2014-05-19 14:51 ` Johannes Berg
2014-05-26 9:06 ` Rostislav Lisovy
2014-05-26 9:35 ` Johannes Berg
2014-05-19 14:49 ` [RFC 2/2] mac80211: Add new interface type for OCB mode Rostislav Lisovy
2014-05-19 14:57 ` Johannes Berg [this message]
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=1400511443.4273.16.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=jan-niklas.meier@volkswagen.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=lisovy@gmail.com \
--cc=rostislav.lisovy@fel.cvut.cz \
--cc=s.sander@nordsys.de \
--cc=sojkam1@fel.cvut.cz \
/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
all inboxes | Powered by JetHome®