From: Florian Sesser <flomaillist@cosetrain.com>
To: linux-wireless@vger.kernel.org
Cc: Benedikt Elser <elser@in.tum.de>
Subject: [RFC/RFT v2] mac80211 / o11s mesh: Modularize Path Selection Protocol
Date: Sun, 08 Feb 2009 20:47:03 +0100 [thread overview]
Message-ID: <498F36B7.40806@cosetrain.com> (raw)
Hi all!
Here is my second version of my abstraction modularizing the o80211s
mesh path selection protocol.
Sorry for taking so long, thanks for your comments!
I once again welcome your suggestions. Please have a look at my
mesh_path_selection_ops: Do you think they will suffice? It seems to me
that they do for mesh_hwmp, but I also might have overseen something
trivial here?
Where are the o11s guys BTW?
Changes from v1:
* Incorporated suggestions from Rami and Johannes, especially:
* checkpatch.pl (sorry 'bout that)
* Moved two or so unnecessary comments to commit msgs
* removed two unnecessary EXPORT_SYMBOLs
(mesh_..._algo_find and mesh_..._algo_set)
* removed mesh_..._find_by_name, use only find(u32 id)
(that only breaks loading missing modules from disk,
but that isn't really needed.)
* keep mesh_hwmp built into mac80211, not as seperate module.
registers itself on load.
* wrote a Kconfig for my mesh_pptest skeleton module (although
I don't think anybody wants this in vanilla?! I merely included
it for reference...)
* Renamed mesh_path_sel_algo_(un)register to
ieee80211_mesh_path_sel_proto_(un)register
* Moved mesh_path_timer/ieee80211_mesh_path_timer from mesh.c
to mesh_pathtbl.c
* Removed the typedefs for the function pointers in mesh_path_sel_ops
and renamed them to avoid 'hungarian notation'
What I didn't do:
* Change seven or so different calls via function pointers to
static inlines. Johannes pointed me to rate_control, but the code
there also isn't explicitly elegant IMHO - half a page of empty
static inlines for the case of an algorithm being *not* used.
Of course that gets compiled out, but the functions here aren't
called very often, and in the case of HWMP, which heavily floods and
by the draft standard is expected to work for mesh networks of up to
32 nodes, the performance benefit is negligible IMHO. [The block
device IO scheduler, where I took most of my inspiration from, also
does not do that - and the functions there do get called a lot.]
What I don't know if I should do:
* The names of the six extra EXPORT_SYMBOLS that are needed by mesh
path selection algorithms (mainly form mesh_pathtbl.c and mesh.c)
begin with mesh_ ... not ieee80211_... . Should I rename them?
Greetings!
Florian
next reply other threads:[~2009-02-08 19:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-08 19:47 Florian Sesser [this message]
2009-02-08 19:52 ` [PATCH 1/3] mac80211: Modularize Mesh path selection protocol Florian Sesser
2009-02-08 19:52 ` [PATCH 2/3] mac80211: Modul. mesh path prot: Comm w/ Userspace Florian Sesser
2009-02-09 10:39 ` Johannes Berg
2009-02-08 19:52 ` [PATCH 3/3] mac80211: Modul. mesh path prot: Skeleton Module Florian Sesser
2009-02-09 10:44 ` Johannes Berg
2009-02-09 11:58 ` Florian Sesser
2009-02-09 12:14 ` Johannes Berg
2009-02-09 10:35 ` [PATCH 1/3] mac80211: Modularize Mesh path selection protocol Johannes Berg
2009-02-08 19:56 ` [PATCH 1/1] iw: Added capability to set individual mesh IDs Florian Sesser
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=498F36B7.40806@cosetrain.com \
--to=flomaillist@cosetrain.com \
--cc=elser@in.tum.de \
--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).